WO2003021444A2

WO2003021444A2 - System and method for monitoring a computer based system

Info

Publication number: WO2003021444A2
Application number: PCT/US2002/027689
Authority: WO
Inventors: Preston E. Corbett
Original assignee: Silas Technologies, Inc.
Priority date: 2001-08-29
Filing date: 2002-08-29
Publication date: 2003-03-13
Also published as: WO2003021444A3

Abstract

A system for monitoring the performance of a target system, where the target . system includes at least one resource to be tested, and that resource performs at least one resource function to be tested. The system includes a monitoring program that sends a resource function test request in one protocol, such as HTTP. A target system interface receives the resource function test request and calls a resource function test program, which sends a resource function test requt:st to the target system in a second protocol that is understood by the target system. The target system interface receives a resource function test response via the resource function test program, and sends the response to the monitoring program. The monitoring program then determines whether the actual response from the resource of the target system is a predefined expected response. If so, the testing cycle continues. If not, notifications are sent to technical support personnel via a notification interface. Upon completion of a testing cycle a web page publisher publishes diagram of the status of the target system.

Description

SYSTEM AND METHOD FOR MONITORING A COMPUTER

BASED SYSTEM

A portion of this disclosure contains material that is subject to copyright protection. The copyright owner consents to the reproduction of the disclosure, as it appears in the Patent and Trademark Office patent files or records, but otherwise reserves all copyright rights whatsoever.

FIELD OF THE INVENTION

The present invention generally relates to a computer software application for monitoring the various resources of a computer system, such as an electronic commerce system.

BACKGROUND OF THE INVENTION

State of the art information systems are extremely complex and are becoming increasingly so. Such information systems are heterogeneous in that they are composed of multiple and diverse computer resources and hardware/software platforms that are integrated together to provide a business function. Legacy systems, which typically use database management systems (DBMSs) running on mainframes or minicomputers, remain deeply embedded in the information infrastructure of many organizations. In order for such businesses to engage in electronic commerce, an Internet presence is necessary. Of course, the web servers that typically provide the Internet presence must be in electronic communication with the legacy systems, which requires a significant amount of telecommunications technology, all of which is inherently complex.

An example of such a heterogeneous computer system would be a commercial cash management application at a financial institution. This system could be composed of one or more web servers for providing access to the system via the Internet, a Unix server functioning as a gateway, and a mainframe application, such as IBM's CICS, running on a mainframe computer system, such as an IBM System 390, which is in electronic communication with a legacy database, such as IBM DB2, also running on a mainframe computer system.

As organizations increasingly depend on such complex computer systems for their daily operations, the monitoring and reporting the performance of the computer system becomes very important. By "monitoring," I mean the testing of a component, or "resource" of a target system. By "target system," I mean the computer system to be monitored. Since a resource may perform more than one function, it is desirable to test the various functions of a resource. The actual resource function test responses are then compared to expected resource function test responses to determine whether the test yielded the expected response, which indicates whether the resource is functioning properly. Of course, if the expected response is not received from the resource tested, notification and corrective action may be indicated.

Prior art solutions are typically limited to monitoring the performance of a specific computer resource, such as a web site. U.S. Patent No. 6,138,157 for Method and Apparatus For Testing Websites is an example of such a limited monitoring solution. They do not, however, permit monitoring of target systems that span multiple and diverse computing platforms, such as the exemplary commercial cash management system described above.

Other known monitoring applications that can test the performance of more complex computer systems are typically based upon the Simple Network Management Protocol ("SNMP"). SNMP is a set of protocols for managing complex networks. Essentially, SNMP-based monitoring applications send requests to the various resources of a network and "agents" gather information and store data about themselves in Management Information Bases (MIBs) and return this data to the SNMP requesters. Agents are programs that perform some information gathering or processing task in the background. Since an agent typically performs a given a very small and well-defined task, the agent based approach to monitoring the performance of a target system requires a large number of agents. The development and maintenance of such agents is a time consuming and expensive task. The time and expense is exacerbated if the functionality of the target system changes, in which case, the agents need to be modified as well. An example of a prior art, agent based approach to monitoring the performance of a target system include a product known as "Patrol," which is available from BMC of Unicenter, California.

Thus, there remains a need for a non-agent based system and method to monitor a complex computer system that is comprised of multiple, diverse resources, and that is also quickly deployed and easily maintained. Known monitoring systems, particularly, agent-based solutions, tend to have complex user interfaces because of the complexity of the target system and the complexity of agent-based monitoring systems. Thus, there is a need for a monitoring system with a user interface that provides a concise view of the status of the target system without over-burdening or overwhelming the technical support personnel, who are responsible for maintaining the target system, with data and information that must be further filtered, analyzed and interpreted.

Notification of technical support personnel in the event that the monitoring system detects an error in the target system is necessary for maintaining the uptime of the target system. By "uptime," I mean the time that the target system is functioning properly and without error. Prior art monitoring solutions typically do not include, or are not tightly integrated with, a notification process. Rather, the monitoring process and the notification process are disjointed and usually require multiple applications that must be integrated, all of which increases the complexity and, therefore, the time and expense in implementing and maintaining the monitoring application. Thus, there remains a need for a system and method for monitoring a complex computer application wherein the notification process is integrated with the monitoring process.

Another issue is that after-the-fact analysis and reporting of resource uptime and target system uptime (a key component of overall customer satisfaction) is usually constructed in a manual or semi-automatic fashion to provide staff and management with a summary of application activity.

SUMMARY OF THE INVENTION

The present invention is directed to a system, method and computer readable media comprising software for monitoring the performance of a target system, where the target system includes at least one resource to be tested, and that resource performs at least one resource function to be tested. The system includes a monitoring program that sends a resource function test request in one protocol for a resource function test. For example, a request for a web page in the hypertext transport protocol ("HTTP"). The resource function test request is sent at a predetermined time interval and includes one or more resource function test parameter for the resource function to be tested. A target system interface receives the resource function test request, and responsive to the resource function test request, calls a resource function test program. The resource function test program sends a resource function test request in a second protocol, ,such as an internet protocol, to the resource to be tested, and receives from the resource function to be tested a resource function test response in the second protocol. The resource function test response is then passed to the monitoring application in the first protocol. The monitoring application then determines if the actual resource function test response is the expected response. If not, technical support personnel, or other computer programs can be notified.

In addition, a web page publisher publishes a web page displaying a target system diagram, which represents the status of the target system, based on one or more resource function test responses from the target system. The target system diagram is displayed via a web based user interface to the monitoring system. The web based user interface also displays a resource function test response time graph and listing, which show information about the amount of time between a request for a resource function test and a response to the resource function test.

The system also includes a database for storing resource function test request information and resource function test response information. The resource function test request information could be uniform resource locator information and post data. The resource function test response information could be expected resource function test response information and actual resource function test response information.

The system of the present invention also provides a user interface for creating a monitor for a target system. A target system monitor is comprised of monitor information and resource function test information for each resource of the target application to be tested. Monitor information consists of test interval information, which is the amount of time between testing cycles if the target system was functioning in an expected manner during the immediately preceding testing cycle. Monitor information also includes retest interval information, which is the amount of time between testing cycles if the target system was not functioning in an expected manner during the immediately preceding testing cycle. The monitor information also includes notification interval information, which is the amount of time between the end of a testing cycle during which the monitoring application program determined that the target system was not functioning in an expected manner and when a notification, such as an email, a page or an SNMP alert, is to be sent indicating the target system was not functioning in an expected manner. The monitor information also includes resource availability information, which is the amount of time that the resource should be functioning in an expected manner.

The present invention is directed to a system, method and computer readable media comprising software for creating a resource function test program to a resource function of at least one resource of a target system, which includes a recorder and a database. The recorder receives information from a user to be input into a resource to be tested and receives the output generated the resource in response to the user input. The input and out information is stored in a database, and a resource function test program is automatically generated based on the input and the output The resource function test program generated can be a web page, such as an active server page, a Java server page or a a common gateway interface bin script.

These and other aspects of the present invention will become apparent to those skilled in the art after a reading of the following description of the preferred embodiments, when considered in conjunction with the drawings. It should be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the invention as claimed.

BRIEF DESCRIPTION OF THE DRAWINGS

Figure 1 is a high level diagram illustrating the overall software architecture of the system of the present invention; Figure 2 is a diagram illustration an Internet implementation of the system of the present invention;

Figure 3 is a screen shot of an exemplary user interface to the General options folder of the Monitoτ Options module;

Figure 4 is a screen shot of an exemplary user interface to the Interval options folder of the Monitor Options module;

Figure 5 is a screen shot of an exemplary user interface to the Service Level Agreement options folder of the Monitor Options module;

Figure 6 is a screen shot of an exemplary user interface to the Proxy options folder of the Monitor Options module; Figure 7 is a screen shot of an exemplary user interface to the Modem options folder of the Monitor Options module;

Figure 8 is a screen shot of an exemplary user interface to the Add Network folder of the Define Network Relationships module;

Figure 9 is a screen shot of an exemplary user interface to the Delete Network folder of the Define Network Relationships module;

Figure 10 is a screen shot of an exemplary user interface to the Reorder Network folder of the Define Network Relationships module;

Figure 11 is a screen shot of an exemplary user interface to the Resource Properties module; Figure 12 is a screen shot of an exemplary user interface to the General options folder of Resource Properties module;

Figure 13 is a screen shot of an exemplary user interface to the Pager List folder of Resource Properties module;

Figure 14 is a screen shot of an exemplary user interface to the Email List folder of Resource Properties module; Figure 15 is a screen shot of an exemplary user interface to the Errors folder of Resource Properties module;

Figure 16 is a screen shot of an exemplary user interface to the Error Maintenance module; Figure 17 is a screen shot of the information displayed by the monitor supervisor;

Figure 18 is a screen shot of an exemplary user interface to the General options folder of the monitor supervisor;

Figure 19 is a screen shot of an exemplary user interface to the Security options folder of the monitor supervisor;

Figure 20 is a screen shot of the information displayed by the monitor supervisor log;

Figure 21 is a screen shot of the information displayed by the on call log;

Figure 22 illustrates the design of an exemplary Monitor table of the monitor database;

Figure 23 illustrates the design of an exemplary Node table of the monitor database;

Figure 24 illustrates the design of an exemplary Monitor Node table of the monitor database; Figure 25 illustrates the design of an exemplary Monitor Design table of the monitor database;

Figure 26 illustrates the design of an exemplary Response Times table of the monitor database;

Figure 27 illustrates the design of an exemplary Log table of the monitor database; Figure 28 illustrates the design of an exemplary Errors table of the monitor database;

Figure 29 illustrates the design of an exemplary ErrorEmail table of the monitor database; Figure 30 illustrates the design of an exemplary ErrorPager table of the monitor database;

Figure 31 illustrates the design of an exemplary NodeEmail table of the monitor database;

Figure 32 illustrates the design of an exemplary NodePager table of the monitor database;

Figure 33 is a diagram illustrating an exemplary ASP library and an exemplary collection of the interface objects, and their relationship to a target system and a monitor;

Figure 34 is a screen shot of an exemplary user interface to the wizard selection module;

Figure 35 is a screen shot of an exemplary user interface to the ODBC Connection wizard;

Figure 36 is a screen shot of an exemplary user interface to the Ping wizard;

Figure 37 is a screen shot of an exemplary user interface to the Telnet wizard; Figure 38 is a screen shot of an exemplary user interface to Event Log wizard;

Figure 39 is a screen shot of an exemplary user interface to Internet Explorer wizard;

Figure 40 is a screen shot of an exemplary user interface to the monitor summary page, which is shown in color to aid in understanding; Figure 41 is a screen shot of an exemplary user interface to monitor results page, which is shown in color to aid in understanding;

Figure 42 is a screen shot of an exemplary user interface to response times listing of the monitor results page, which is shown in color to aid in understanding;

Figure 43 is a screen shot of an exemplary user interface to the modify error message information module;

Figure 44 is a screen shot of an exemplary user interface to the monitor error log;

Figure 45 is a screen shot of an exemplary user interface to the on call module;

Figure 46 is a screen shot of an exemplary user interface for paging an employee;

Figure 47 is a screen shot of an exemplary user interface for paging a group of on call employees;

Figure 48 is a screen shot of an exemplary user interface for adding new employee information; Figure 49 is a screen shot of an exemplary user interface for modifying employee information;

Figure 50 is a screen shot of an exemplary on call schedule for an employee;

Figure 51 is a screen shot of an exemplary user interface for adding an application group to an on call schedule; Figure 52 is a screen shot of an exemplary user interface for modifying an application group;

Figure 53 is a screen shot of an exemplary user interface for creating or modifying the on call schedule for an application group;

Figure 54 is a screen shot of an exemplary on call schedule for an employee;. Figure 55 illustrates the design of an exemplary the Employee table of the on call database;

Figure 56 illustrates the design of an exemplary the Call Schedule table of the on call database;

Figure 57 illustrates the design of an exemplary the Paging Provider table of the on call database;

Figure 58 illustrates the design of an exemplary the ContactLog table of the on call database;

Figure 59 illustrates the design of an exemplary the Groups table of the on call database; Figure 60 is a screen shot of an exemplary user interface to the Application

Selection web page of the Configurations module;

Figure 61 is a screen shot of an exemplary user interface to the Monitor Configuration web page of the Configurations module;

Figure 62 is a screen shot of an exemplary user interface to the Reports module;

Figure 63 is a screen shot of an exemplary availability by resource report;

Figure 64 is a screen shot of an exemplary resource error log;

Figure 65 is a screen shot of an exemplary average response times by resources chart; Figure 66 is a screen shot of an exemplary user interface to the reporting system web page;

Figure 67 is a screen shot of an exemplary average response times by resource report;

Figure 68 is a screen shot of an exemplary availability by application report; Figure 69 is a screen shot of an exemplary target system error log; Figure 70 is a screen shot of an exemplary error log by application and date report; and

Figure 71 is a screen shot of exemplary customer experience report.

DETAILED DESCRIPTION OF PREFERRED EMBODIMENT The subheadings used herein are meant only to aid the reader and are not meant to be limiting or controlling upon the invention. Generally, the contents of each subheading are readily utilized in the other subheadings. • System Overview

The system 10 in accordance with the present invention is illustrated in Figure 1. The target system 2 is the computer-based business process or system to be monitored. The target system 2 consists of the logical components of the business process or system, such as, a Web server, a mainframe software application, a communications connection or a database. In one exemplary embodiment, the target system is a commercial cash management system comprised of one or more web servers for providing access to the system via the Internet, a Unix server functioning as a gateway, and a mainframe application, such as IBM's C1CS, running on a mainframe computer system, such as an IBM System 390, which is in electromc communication with a legacy database, such as IBM DB2, also running on a mainframe computer system. The monitoring application 4 is a computer software application that is responsible for running one or more target system monitors. Preferably, the monitoring application is written using the Visual Basic programming language. Of course, the monitoring application could be written using any procedural or object oriented programming language, for example, C++. A target system monitor can be thought of as a collection of information about the various resources of the target system and the functions performed by the various resources of the target system. The target system monitor also includes information necessary to test each function of each resource comprising the target system and information about the expected response from each resource function when the resource function is tested. The monitoring application also includes a user interface (not shown) for creating a target system monitor. The process of creating a target system monitor will be discussed in more detail below.

Another component of the monitoring application is the notification interface. The notification interface is responsible for providing notification to technical support personnel in the event that the target system being monitored is not performing in the expected manner. The notification interface will be discussed in more detail below.

The target system interface 6 is responsible for the electronic communications between the momtoring application 4 and the target system 2. Specifically, the target system interface receives resource function test requests from the monitoring application 4 and translates those resource function test requests into a format that can be understood by the target system resource to be tested. After translating the resource function test requests, the target system interface 6 exercises the target system 2. By "exercising" the target system 2, 1 mean actually testing the resource function according to the parameters contained in the resource function test request received from the monitoring application 4. In response to the resource function test request, the target system 2 generates a response, which is sent to the target system interface 6. The target system interface 6 translates the response to the resource function test request back into a format that can be understood by the monitoring application 4, and sends the reformatted resource function test request response to the monitoring application 4 for further processing by the monitoring apphcation 4. The wizards 8 are programs that are called via the user interface to the monitoring application 4, and automatically generate programs for testing a target system resource function. In the preferred embodiment, a resource function test program is an active server pages ("ASP") that is executed by a web server program (not shown), which is a part of the target system interface. The wizards 8 will be discussed in more detail below.

In a preferred embodiment, the monitoring application 4 and the target system interface 6 are installed and operate on a computer system running any of the Windows 32-bit server operating system, such as the Windows NT Server 4.0 or Windows 2000 Server operating systems, which are available from Microsoft

Corporation of Redmond, Washington. The computer system upon which the monitoring application 4 and target system interface 6 are operating should meet the following minimum requirements:

128 megabytes (MB) of random access memory • Pentium-class processor

32,768 color video card 50-100 MB free memory on the server 61,670 KB free on server to install the application software Windows NT Server Service Pack 5 or higher • Windows NT Options Pack (including IIS, MTS, SMTP)

Microsoft Internet Explorer version 4.X, or higher • The Monitoring Application 4

Figure 2 illustrates an Internet implementation of the present invention. As seen in Figure 2, the main components of the monitoring application 4 are the user interface 40, the monitor supervisor 41 , the monitors that are running 42, the monitor database 43, the ITC 44, and the Notification Interface 45. Each of these components will be discussed in more detail below. • User Interface 40

As can be seen in Figure 2, the monitoring application 4 includes a user interface 40, which allows a user to create a monitor for a specific target system and establish the parameters for the monitor, define network/server relationships, set the action and response to be monitored, set the monitor schedule, specify how support personnel are notified of "errors" in responses from the target system, and view information about the errors. An "error" occurs when the actual response from a resource function of a target system is not the expected response. In the preferred embodiment, the information pertaining to the monitor is stored in the monitor database 43.

• Creating Monitors 42 To create a monitor 42, the business purpose of the target system 2 should first be understood. This includes identifying the high-level process that the target system

2 facilitates. The need for human intervention with respect to the target system should be determined, and users and persons responsible for maintaining the target system 2 should be identified. The reasons for monitoring the target system 2, such as, providing operations support, ensuring compliance with business unit service level agreements, and troubleshooting, should be understood.

Next, each of the resources of the target system to be monitored should be identified. Resources are specific components of the target system 2 and should be a logical component of the target system 2, such as, a database, software application, a Web server, or a communications connection. Next, each function for each resource of the target system should be defined. Each resource may have one or many related resource functions, such as, "pinging" a server, logging onto a secured system, executing a transaction to be recorded in a database, the navigation of a certain path through a Web site, or displaying a certain status code that indicates a user has completed processing a document. Next, the actions to be taken, if any, based upon responses of the resource should be specified. For example, if the system 10 indicates that a resource is not functioning properly, technical support personnel can be notified so that the problem can be evaluated.

Returning to Figure 2, once the target system 2 is understood, a target system monitor 42 must be created before a target system 2 can be monitored. In the system

10 of the present invention, individual target system monitors 42 are created to test the target system 2 as specified by the user. Each monitor 42 uses information entered by the user to test the target system 2 on a regular time interval, notifying appropriate support personnel if any errors occur. The monitor information entered by the user is stored in a monitor database 43, which is discussed in more detail below.

The system of the present invention advantageously provides for a Monitor Options module for entering information necessary for the creation of a target system monitor. Figure 3 illustrates an exemplary user interface 30 to the Monitor Options module. As can be seen in Figure 3, a user can specify genera] options, interval options, service level agreement option, proxy options and modem options via the Genera] options folder 31 , the Interval options folder 32, the Service Level Agreement options folder 33, the Proxy options folder 34, and the Modem options folder 35, respectively, all of which are discussed in more detail below. • General Options General options folder 31 allows the user to enter the name of the monitor in the Application Monitor Name field and description of the monitor in the Description field. The Include On Web Home Page checkbox should be selected to display the monitor on the monitor summary page, which preferably is an active server (ASP) page, and is discussed in more detail below. In the Home Page Position field, the user enters a number that corresponds to the order in which the monitor results displayed on the monitor summary page. For example, if "3" is entered in the Home Page Position field, the monitor will be the third monitored displayed on the monitor summary page. The Web Physical Directory field contains information about the physical path for the location of the monitor summary page. The Web Virtual Directory field 31 OF contains information about the corresponding virtual path. A virtual path specifies a mapping between the virtual path in a URL and the physical path on a device.

The Email Address field is used to specify the e-mail address that will be listed in the From field on all e-mail messages sent by the system of the present invention. In the Email Gabby Errors drop down box, the user specifies the technical support personnel who should receive e-mail notices in event of an error. A list of available technical support personnel can be specified in the On Call module, which is discussed in more detail below. The Test Only checkbox is selected to disable sending pages or emails to technical support personnel when the monitor identifies an error in the target system. • Interval Options Figure 4 illustrates an exemplary user interface to the Interval options folder 32 of the monitor options. The Interval options folder 32 allows a user to specify how often the monitor runs and the level of technical support and management that is connected with any identified error. For example, if the value entered in the Start Testing Cycle field is "5," the monitor will test the target system every five minutes. Should an error be detected, the test cycle interval may be varied, or shortened by entering a value in the If Application Errors Exist, Start Test Cycle field. This allows technical support personnel to determine in a shorter time frame when the error has been corrected. The Page/Email Primary Support field allows the user to specify the amount of time in minutes after an error has occurred to page or e-mail the target system's primary technical support personnel. The Page Secondary Support field, Page Tertiary Support field, Page Level 4 Support field and Page Level 5 Support field allows the user to specify multiple levels of technical support according to the values entered in these fields.

• Service Level Agreement Options Figure 5 illustrates an exemplary user interface to the Service Level Agreement options folder 33 of the Monitor Options module. As shown in Figure 5, the service level agreement options folder 33 allows the user to specify thresholds agreed upon for application availability. The value entered in the Warning Threshold field indicates the level of availability at which a warning should be issued. The value in the Critical Threshold field indicates the level of availability at which the service level agreement is broken. For example, if an agreement has been made that a resource, such as a server, will be available 98% of the time, the user can enter values in the Warning Threshold field and the Critical Threshold field that identifies the levels of availability. The Warning Threshold, represented by the color yellow, indicates that the availability level is below the warning level that the user specified but is not below the availability specified in the service level agreement. The Critical Threshold, represented by the color red, indicates that the availability level has decreased to below the availability specified in the service level agreement. The service level agreement results can be displayed on the monitor summary page.

• Proxy Options

Figure 6 illustrates an exemplary user interface to the Proxy options folder 34 of the Monitor Options module. As shown, in Figure 6, the Proxy Options folder 34 allows the user to enter a user name via the Proxy UserName field and a password via the Proxy Password field, if the system is using a proxy server. A proxy server is a server that sits between a client application, such as a Web browser, and a web server.. The proxy server intercepts all requests to the web server and determines whether the proxy server can respond to the request without accessing the web server. If proxy server cannot respond to the request, it forwards the request to the web server.

• Modem Options

Figure 7 illustrates an exemplary user interface to the Modem options folder 35 of the Monitor Options module. Returning to Figure 2, the notification interface 45, which is discussed in more detail below, can be configured to send pages to a system administrator or technical support personnel via the HTTP protocol, e-mail, and via modem. The system selects the most efficient method to use first. If that method fails for some reason, the system will use one of the other two methods. Typically, the HTTP protocol is preferred. Returning to Figure 7, the Modem options folder 35, allows a user to specify the modem settings to be used to page technical support or managerial personnel.

• Network and Server Relationships The system of the present invention monitors individual resources that connect to other resources to form networks, all of which collectively comprise the target system. Figure 8 illustrates an exemplary user interface 80 to a Define Network Relationships module, which allows these networks to be specified for each target system that is to be monitored. The Define Network Relationships module permits the user to specify the relationships between resources that are to be monitored. Similarly, the system permits network relationships to be reordered or deleted as resources change.

Figure 8 illustrates an exemplary user interface to the Add Network folder 81 of the Define Network Relationships module. The first step in defining the resource relationships of a target system is to specify a web server. A web server is first specified because system of the present invention preferably uses the HTTP protocol to send to and receive from the target system interface information about resource function tests and test results, to display the monitor information via the web based interface and to provide notification to technical support personnel via the notification interface. Since the web server is the first resource specified, it can be thought of as a "Tier 1 server." As shown in Figure 8, the name of the web server is entered into the Web Server field of the Add Network folder 81.

Similarly, the next resource, that is, a Tier 2 server is specified. An exemplary Tier 2 server is a Unix gateway server. As shown in Figure 8, the name of this resource is entered into the Tier 2 Server field.

In a similar fashion, the next resource, a Tier 3 server, such as a mainframe computer running a CICS application, is specified by entering its name in the Tier 3

Server field.

While the exemplary embodiment of the present invention uses three tiers of servers, i.e., resources, those skilled in the art can readily appreciate that the present system can be easily modified to add as many tiers of resources as are desired in defining the target system. The system of the present invention allows a resource to be inserted into or deleted from an existing set of resource relationships via the Add Network folder 81. As illustrated in Figure 8, a new resource is interested by specifying the resource after which the new resource is to be inserted in the Inset After field. The new resource also can be inserted at the top a relationship of networks by entering "Top" in the

Insert After field.

Figure 9 illustrates an exemplary user interface to the Delete Network folder 82 of the Define Network Relationships module, which allows for the deletion of a resource. As shown in Figure 9, a network (i.e., a resource) can be deleted from a target system monitor by specifying the resource via the Select Network Relationship field and selecting the Delete button.

Figure 10 illustrates an exemplary user interface to the Reorder Network folder 83 of the Define Network Relationships module, which allows the specification of the testing order of the resources of the target system. As shown in Figure 10, the network, or resource, to be moved is selected and dragged to its new position in the list of resources in the testing order window 83A. The change is confirmed and the networks are thereafter tested in the new order specified in the testing order window. Returning to Figure 2, it should be noted that all of the information necessary to create a target system monitor 42, including the information provided via the user interface 40, is stored in the monitor database 43, which is discussed in more detail below.

• Setting the Resource Function and Response to Monitor When the system of the present invention monitors a target system, it is observing how a particular resource of the target system performs a particular function, and the responses thereto, in order to determine if the resource is functioning properly. The actions and responses that are specified are referred to herein as "resource functions" because they define how a particular resource should function. The resource function settings will vary depending upon the nature of the resource.

The system of the present invention advantageously provides two ways to specify a resource function to be monitored. The information can be manually entered, or alternatively, the information can be captured automatically by "exercising" the application and recording the input to and output from the resource function. Regardless of how the resource function information is entered into the system, it is stored in the monitor database, which is discussed in more detail below. • Manually Entering Resource Function Information

Resource function information can be manually entered via a Resource Properties module. Figure 1 1 illustrates an exemplary user interface 1 10 to the Resource Properties module.

As shown in Figure 11 , the name of the resource is entered in the Resource field. For example, the resource can be a web site.

The value in the SEQ field indicates the order in which resource functions are to be tested. For example, a value of "5" would indicate that the resource function is tested fifth in the resource function test sequence. (A resource function test sequence is the sequence in which all of the functions of a resource are tested.) In other words, resource functions are tested in ascending order beginning with the resource function with the lowest value in the SEQ field. A user can navigate between the various resource functions in a resource function test sequence via the horizontal scroll bar. A Copy button advantageously allows resource function test information to be copied from an existing monitor and resource. The Description field allows for the entry of an identifier or explanation of the resource function. The string entered into the Description field will appear on the monitor summary page, which is displayed via the web-based user interface and is discussed in more detail below.

The URL field is used to specify the Uniform Resource Locator information, which is the address of a resource accessible via the Internet, including any queries to be run on the resource.

The Post Data field specifies any form data that the resource (i.e., web server) may be expecting along with the URL information.

The Response field contains any string that is likely to be found in the web page returned from the web server. If the HTML code returned to the monitoring application includes the string that is entered into the Response field, then the resource that was tested is functioning properly, unless the Not checkbox is selected.

The User Name, Password and Domain fields contain user name, password and domain information that may be needed to access the resource function to be tested if authentication is required in order to do so.

A Setup button 110A can be selected to launch one of several "wizards," which are discussed more detail below.

• Automatically Capturing Resource Function Information As previously mentioned, alternatively, the information needed to test a resource function can be more or less automatically captured using predefined scripts, sometimes referred to herein as "wizards." Preferably, a wizard is an executable ActiveX program that assists user in defining a resource function and an expected response for the resource function.

In a preferred embodiment, the system of the present invention includes wizards for capturing information for several different resource function tests. A wizard either generates an Active Server Page ("ASP") for testing a resource function, or captures information used by, and passed to, a predefined ASP for testing a resource function. Each of the wizards of the preferred embodiment of the system of the present invention will be discussed in more detail below in connection with the corresponding ASP.

• Setting Monitor Schedule and Error Notification Options The system of the present invention advantageously allows for specifying a monitor schedule, a pager list, an e-mail list, and how errors are to be handled for each resource function sequence of the target system. (As mentioned above, an "error" occurs when the actual response received from a resource is not the expected response or does not contain the expected response.)

Figure 12 illustrates an exemplary user interface to the General options folder 120 of the Resource Properties module. As shown in Figure 12, for each resource function sequence specified via the Resource Properties module, the time of day that the monitoring is to occur is specified via the Monitor From field and the TO field.

The specific days of the week the target system resource is to be monitored is specified by selecting the checkbox(es) associated with each day of the week. In the preferred embodiment, the amount of time the monitor will attempt to exercise the resource before returning a time-out error is specified in the Seconds Before Timeout field. Preferably, a resource can be temporarily disabled while a monitor is running by selecting he Resource Disabled box. Alternatively, rather than disabling the resource, the notification that the resource is not functioning properly can be disabled. Another alternative is that a monitor can be configured so that a resource continues to be tested even if an error, particularly, an unresolved error, has occurred by selecting the Always Run This Test field. Similarly, if a resource should not be tested after an error has occurred, the Stop Further Tests On Error field can be selected. If the Stop Further Tests On Error field is selected, and an error occurs on the resource, the resource is represented in the color red on the target system diagram that is displayed via the web-based user interface. Otherwise, the resource is represented the color yellow. The system can be configured to stop any e-mail or pager notifications from being sent and for testing to continue despite any errors by selecting the Disregard Any Errors field. A resource's response times can be logged and saved in the monitor database and/or displayed in a response time graph via the web-based user interface by selecting the Log and Graph Response Times field. Preferably, the system can be configured so that the availability of a resource is included in a service level agreement report by selecting the Include in SLA Reports field. The system also can be configured so that a resource can be shown on an alerts page via the web-based user interface, which is discussed in more detail below, by selecting the Include on Alerts Page field. Returning to Figure 2, the system 10 of the present invention can be configured to cause notification of technical support personnel via the Notification Interface 45. As illustrated in Figure 13, for example, the technical support group to be paged in the event of a specific error can be specified via the Pager List folder 130. Similarly, as shown in Figure 14, the specific technical support personnel to be sent an email in the event of a specific error can be specified via the Email List folder 140.

Returning to Figure 2, it should be noted that technical support groups to be paged and employees to be sent an email in the event of an error can be modified via the web-based user interface 65, which is discussed in more detail below.

Figure 15 illustrates an exemplary user interface to the Error folder 150 of the Resource Properties module. As shown in Figure 15, for each resource function sequence, the course of action to be taken when an error occurs is specified via the Errors folder 150. The Errors folder 150 will display the current error (if one exists) in the Current Error field 150A and the course of action taken in the event of the error specified in the Current Error field 150A can be specified in the Course of Action field 150B. This information can be edited, as desired, by selecting Error

Maintenance button 151, which launches an Error Maintenance module.

Figure 16 shows an exemplary user interface 160 to the Error Maintenance module. As shown in Figure 16, the General folder 161 shows he resource to which the error applies in the Resource field 1610A. It should be noted that the system of the present invention is advantageously configured so that the Resource field, and other fields shown in the General folder 161 , may already be populated with error information, depending upon the particular error that occurred. The number of times the particular error has occurred and the time that it last occurred can be entered, or is shown, is shown in This Error Has Occurred field and the Last Occurred field. To include the information about the particular error in a Service Level Agreement report, the Include Logs With This Error In SLA Reports field is selected. The error message that displays on the monitor's results page can be entered, or is shown, in the Error Message Interpreted For Display field. The actual error message is displayed in the Actual Error Message Received field, which cannot be edited via the Error Maintenance module. A predetermined error message can be displayed in connection with a particular type of error in by entering the error message in the Common Part of Error Message field. For example, if "threshold exceeded" is part of an error message that frequently occurs, that string should be entered in the Common Part of Error Message field, and the string "Resource Taking Too Long to Respond" can be entered in the Error Message Inteφreted For Display field. A particular course of action can be specified by an entry in the Course of Action field.

• The Monitor Supervisor 41

Returning to Figure 2, the monitor supervisor 41 performs system maintenance checks, backs up the monitor database 43 and launches target system monitors 42.

When the monitoring application 4 is launched, the monitor supervisor 41 verifies that the computer system upon which the monitoring application 4 has been installed has an operating Internet connection. The monitor supervisor 41 is also . responsible for deleting old logs or images. The monitor supervisor 41 then loads the target system monitors 42.

An example of the information displayed by the monitor supervisor 41 via the user interface 40 is shown in Figure 17. As can be seen in Figure 17, the monitor supervisor displays the date and time of monitor supervisor started. The monitor supervisor also displays information about backing up, repairing, and compressing of the monitor database and the on call database. Following that, monitor supervisor displays messages indicating that old response times, database logs, and images have been deleted. Finally, information identifying the monitors that have been launched by the watchdog supervisor is displayed.

Figure 18 illustrates an exemplary user interface to the General options folder 181 of the monitor supervisor. The General options folder 181 ofthe monitor supervisor allows the system administrator to specify how often the monitor supervisor backs up the monitor database, how old logs or data should be deleted, and the location of all directories and logs.

Figure 19 illustrates an exemplary user interface to the Security options folder 182 of the monitor supervisor. As can be seen in Figure 19, a system administrator can specify which groups of users can have access to or change certain types of information within the system.

Figure 20 illustrates the information displayed by the monitor supervisor log. As can be seen in Figure 20, the monitor supervisor log displays a list of all errors and activities that have occurred, the date and time that the activity/error occurred and a description of the activity/error.

Figure 21 illustrates the information displayed by the on call log. As can be seen from Figure 21 , the on call log that displays all activities that have occurred with respect to employees or support personnel who are associated with and are on call for specific resource and/or target system. The system administrator may clear the information in either of the above logs from the monitor supervisor window. • The Monitor Database 43

Returning to Figure 2, the monitor database 43 stores information pertinent to each target system monitor 42 created via the user interface 40. In the preferred embodiment, the monitor database 43 is a relational database, such as Microsoft

Access, which is available from Microsoft Coφoration of Redmond, Washington. As can be appreciated by one skilled in the art, however, any computerized database is suitable for storing monitor information. The monitor database 43 includes several tables, each of which will be described in turn in exemplary detail. The monitor table 220 shown in Figure 22 contains the information that is relevant to each target system monitor. Preferably, there is one record in the monitor table for each target system monitor. The monitor table includes the following fields of information:

Monitor- name of the monitor, which is input via the general options folder. Description - a description of the monitor, which is input via the general options folder.

TestOnly - if the value in this field is 0, pages or e-mails are sent to support personnel when the monitor identifies an error with the target system being monitored. If value is 1 , pages or emails are not sent. A value can be entered into the TestOnly field via the General Options folder.

Interval - indicates the number of minutes between testing cycles, which is input via the Interval Options folder.

Retestlnterval — indicates the number of minutes between testing cycles once a resource function error has been detected. This value is also input via the Interval Options folder.

MinsBeforePage — indicates the number of minutes after an error occurs that the system should wait before sending a page or e-mail to the resource's primary technical support personnel. This value is also input via the Interval Options folder.

MinsBeforePaging Secondary Support, Tertiary Support, Level 4, and Level 5 Support — indicates the number of minutes after an error occurs that the system should wait before sending a page or e-mail to the resource's secondary, tertiary, Level 4 and Level 5 technical support personnel. This value is also input via the Interval Options folder.

Top — the value entered in this field is preferably in τwips, but could be any x-y coordinate system used by a computer display, and represents the position of the target system diagram relative to the top of the web page that displays the target system diagram

Left — the value entered in this field is preferably in twips, but could be any x- y coordinate system used by a computer display, and represents the position of the target system diagram relative to the left side of the web page that displays the target system diagram

Right — the value entered in this field is preferably in twips, but could be any x-y coordinate system used by a computer display, and represents the position of the target system diagram relative to the right side of the web page that displays the target system diagram

Width — the value entered in this field is preferably in twips, but could be any x-y coordinate system used by a computer display, and represents the width of the target system diagram

MonitorGroup - the value entered in this field is the group to which the monitor is assigned

MonitorGroupSequence — the value entered in this field represents the sequence in which the monitor is displayed on the monitor summary page

SLAYellowPercentage - indicates the percentage of resource availability below which the representation of the resource in Availability by Application report rums yellow. This value is entered via the SLA Options folder.

SLARedPercentage - indicates the percentage of resource availability below which the representation of the resource in Availability by Application report turns red (critical). This value is also entered via the Options folder SLA and should be less than the value entered in the SLA Yellow Percentage field The monitor database also includes a node table 230 shown in Figure 23. The node table contains information about each node, i.e., resource of each monitor. Preferably, there is a record in the node table for each resource of the target system being monitored. The information stored in the node table can be entered manually via the user interface or automatically via one of the resource wizards, which are discussed in more detail below. The node table contains the following fields of information:

Monitor -name of the monitor, which is input via the General Options folder.

Node - the name of the resource that is entered via the Resource Properties module. Sort Order - corresponds to the SEQ (sequence) value that is entered in the

Resource Properties module.

URL - specifies the path to the resource that is entered via the Resource Properties module. The URL field also will contain any information entered into the Post Data field via the Resource Properties module. Action - this field will contains any information entered into the Post Data field via the Resource Properties module.

.Error Number - indicates the number of times that the error has occurred during a specified period. This field is populated by the monitoring application as errors occur. Last Error Date - indicates the most recent date that a particular error occurred. This field is populated by the monitoring application as errors occur.

Last Error Time - provides the time of day that the last error occurred. This is populated by the monitoring application as errors occur.

Stop On Error field - if the value in this field is 1, the system will not test the resource further upon detecting an error. If the value 0, if an error in the resource is detected, the system will continue to test the resource pursuant to the information entered via the General Options folder of the Resource Properties module.

Start Time - indicates the time of day that the testing cycle for the resource will begin, which is entered via information entered via the General Options folder of the Resource Properties module. Stop Time — indicates the time of day that the testing cycles for the resource will end, which is also entered via information entered via the General Options folder of the Resource Properties module.

Anticipated Response - indicates the string that should be contained in the expected response that is returned when a resource is exercised by the monitor. This value can be entered via the General Options folder of the Resource Properties module.

Timeout - indicates the number of seconds that the monitor will attempt to exercise a resource before returning a time-out error. This value is entered via the General Options folder of the Resource Properties module.

Schedule - a seven (7)-digit field that indicates the days of the week testing of the resource will occur. For example, a value of 0 in the first field indicates the resource will not be tested on Monday and a non-zero value indicates that the resource will be tested on that day. These values are entered via the General Options folder of the Resource Properties module.

Always Run - indicates that the resource will be tested regardless of whether additional errors occur in the resource. This value is entered via the Geneτal Options folder of the Resource Properties module.

Description - specifies the message that will display via the web-based user interface when the anticipated response is returned from the resource. This value is entered via the Error Maintenance module or Resource Properties module.

Graph Times — indicates whether a resource's response times will be stored in the monitor database and converted into a graphical display in the target system diagram that is displayed via the web-based user interface. This value is entered via the General Options folder of the Resource Properties module. DisregardError — indicates that no pages or e-mails will be sent to technical support personnel via the Notification Interface regardless of whether errors occur. This value is entered via the General Options folder of the Resource Properties module. Pagedl — a zero value in this field indicates that Level 1 technical support personnel has not been paged; a non-zero value indicates that Level 1 technical support personnel has been paged.

Paged2 - a zero value in this field indicates that Level 2 technical support personnel has not been paged; a non-zero value indicates that Level 2 technical support personnel has been paged.

Paged3 — a zero value in this field indicates that Level 3 technical support personnel has not been paged; a non-zero value indicates that Level 3 technical support personnel has been paged.

Paged4 — a zero value in this field indicates that Level 4 technical support personnel has not been paged; a non-zero value indicates that Level 4 technical support personnel has been paged.

Paged5 - a zero value in this field indicates that Level 5 technical support personnel has not been paged; a non-zero value indicates that Level 5 technical support personnel has been paged. NotResponse - a non-zero value in this field means that if the string identified in Anticipated Response field is not contained in the actual response from the resource, an error has occurred.

SLA - the value in this field indicates whether the resource availability will be incoφorated into a Service Level Agreement report. This value is entered via the General Options folder of the Resource Properties module. Alerts - specifies whether the resource's errors will be listed on the main Alerts page, which is displayed via the web-based user interface. This value is entered via the General Options folder of the Resource Properties module.

Also included within the monitor database is a monitor node table 240 shown in Figure 24, which includes information that controls how monitor is displayed in the target system diagram. Preferably, there is a record for each node, i.e., resource, of the target system monitor. The monitor node table contains the following fields of information:

Monitor - the text in this field is the name of the monitor and will be displayed on the target system diagram.

Node - the value in this field is the name of the resource and will be displayed on the target system diagram.

TextLinel - the text in this field is displayed as the first line of text in connection with the node identified in the node field. TextLine2 - the text in this field is displayed as the second line of text in connection with the node identified in the node field.

Graphic - the value in this field is the path to a graphic image that is displayed in connection with the node.

Font Size - the value in this field controls the font size of the text in the TextLinel and TextLine2 fields.

Font Bold — a non-zero value in this field means that the text in the text in the TextLinel and TextLine2 fields will be displayed in a bold font.

Also included in the monitor database is a monitor design table 250, shown in Figure 25, which includes information that controls how target system monitor is displayed in the target system diagram. As shown in Figure 25, the monitor node table contains the following fields of information:

Monitor — the value in this field is the name of the target system monitor, which is entered via the General Options folder of the Monitor Options module. The value entered in the monitor field is the value that will be displayed in the target system diagram.

SortOrder - specifies the sequence in each resource function sequence is to be tested. The value in this field is entered via the Add Network folder of the Define Network Relationships module.

WeblD — the value in this field identifies the web server of the target system, and is input via the Add Network folder of the Define Network Relationships module.

The value entered in this field is the value that will be displayed in the target system diagram.

ServerlD — the value in this field identifies the Tier 2 server of the target system, and is input via the Add Network folder of the Define Network Relationships module. The value entered in this field is the value that will be displayed in the target system diagram.

CICSID - the value in this field identifies the Tier 3 server of the target system, and is input via the Add Network folder of the Define Network Relationships module. The value entered in this field is the value that will be displayed in the target system diagram.

WebTop — the value entered in this field is the position of the web, or Tier 1, server on the target system diagram relative to the top of the web page that displays the target system diagram

WebLeft — the value entered in this field is the position of the web, or Tier 1 , server on the target system diagram relative to the left side of the web page that displays the target system diagram.

Server Top - the value entered in this field is the position of the Tier 2 server on the target system diagram relative to the top of the web page that displays the target system diagram. ServerLeft - the value entered in this field is the position of the Tier 2 server on the target system diagram relative to the left side of the web page that displays the target system diagram.

CICSTop - the value entered in this field is the position of the Tier 3 server on the target system diagram relative to the top of the web page that displays the target system diagram.

CICSLeft - the value entered in this field is the position of the Tier 3 server on the target system diagram relative to the left side of the web page that displays the target system diagram.

Also included within the monitor database is a Response Times table 260, shown as Figure 26. The Response Times table displays the response time information for each monitor. The table contains the following fields of information:

Monitor - identifies the monitor for which the response time information is stored.

Node - identifies the node for which the response time information is stored. SortOrder — corresponds to the SEQ (sequence) value that is entered in the

Resource Properties module.

RespDate - the date and time that the most recent response information was recorded.

RespTime — the amount of time for the response to be received by the system. Also included within the monitor database is a Log table 270, shown as Figure 27. The Log table provides, in summary fashion, log entries with respect to any error encountered by the system in testing a resource. The Log table contains the following fields of information:

LogDate - the date that the target system was monitored. LogTime - the time that the target system was monitored.

Monitor - the name of the monitor to which the log information pertains.

Node - the name of the monitor to which the log information pertains.

SortOrder — corresponds to the SEQ (sequence) value that is entered in the Resource Properties module. Error Number — the sequential number assigned to the error.

Also included within the monitor database is an Errors table 280, shown as Figure 28. The Errors table contains the following fields of information:

ErrorNum — the sequential number assigned to the error.

Node - the name of the monitor to which the error information pertains. ErrorMsg - the message returned by the system upon detection of the error.

CourseofAction — the course of action specified for the type of error.

HasOccurred - the number of times the error has occurred during a given period.

LastOccurredDate - the date on which this error last occurred. LastOccurredTime - the time of day when the error last occurred.

PageOnlyS witch — a non-zero value means that predefined page notification information is overridden and only technical support personnel specifically associated with the particular error message are paged in the event of the error.

EmailOnlySwitch - a non-zero value means that predefined email notification information is overridden and only technical support personnel specifically associated with the particular error message are emailed in the event of the error.

SLA - a non-zero value indicates that the error information is to be included in is an SLA.

Also included within the monitor database is an ErrorEmail table 290, shown as Figure 29. This table details for each error encountered by the system which employee was notified by electronic mail. The ErrorEmail table contains the following fields of information:

ErrorNum — the sequential number assigned to the error. .

EmployeelD - identifies the employee who is to be notified of the error by email.

Also included within the monitor database is an ErrorPager table 300, shown as Figure 30. This table details for each enor encountered by the system which group of employees was paged. The ErrorPager table contains the following fields of information: EnorNum — the sequential number assigned to the error.

GroupID - the identification of the group that is to be paged on occurrence of the error.

Also included within the monitor database is an NodeEmail table 310, shown as Figure 31. The NodeEmail table contains information as to the technical support personnel to whom an email is to be sent in the event of an error is detected in a node, i.e., resource. The NodeEmail table contains the following fields of information:

Monitor - identifies the monitor for which the email information is stored.

Node - identifies the node for which the email information is stored.

SortOrder- corresponds to the SEQ (sequence) value that is entered in the Resource Properties module. EmployeelD — identifies the employee to whom an email is to be sent in the event of that an error is detected in the node identified in the Node field.

Also included within the monitor database is an NodePager table 320, shown as Figure 32. The NodePager table contains information as to the technical support personnel to be paged in the event of an error is detected in a node, i.e., resource. The

NodePager table contains the following fields of information:

Monitor- identifies the monitor for which the pager information is stored.

Node - identifies the node for which the email information is stored.

SortOrder- corresponds to the SEQ (sequence) value that is entered in the Resource Properties module .

GroupID - identifies the technical support group to be paged in the event of that an enor is detected in the node identified in the Node field.

• The ITC 44

Returning to Figure 2, the system 10 also includes an Internet transfer control ("ITC") 44, Λvhich is an ActiveX control available from Microsoft Coφoration of

Redmond, Washington. The ITC provides implementation of one of the most widely used protocols on the Internet, HTTP. As is known in the art, the HTTP protocol is used to connect to a web server 61 to retrieve web pages, i.e., HTML documents.

• The Notification Interface 45 Returning to Figure 2, the system 10 includes a notification interface 45, which provides for the notification of technical support personnel in the manner specified by the user. The notification interface 45 also can cause the notification of another computer system in the event of an error. For example, the notification interface 45 can cause the issuance of an SNMP trap to another monitoring system. Alternatively, the notification interface 45 can open a problem ticket in a problem management system. Preferably, for each resource function sequence, the technical support personnel, or other computer system, to be notified in the event of an error are specified.

Returning to Figure 13, and as discussed above, technical support personnel to be paged in the event of a resource function error are specified via the Pager List folder 1300. A pager list can be specified for each resource function sequence that is established via the Resource Properties module.

Similarly, returning to Figure 14, and as discussed above, for each resource function sequence, the technical support personnel to whom an email message should be sent in the event of an error are specified via the E-Mail List folder 140. The information specified in via the Pager List folder and the E-Mail List folder, as well as other information used in connection with notification of technical support personnel, is stored in the monitor database, which is discussed above, and the on call database, which is discussed in more detail below. • The Target System Interface 6

Returning to Figure 2, the target system interface 6 is includes a transaction server 60, a web server 61 , a library of active server pages 62, a collection of interface objects 63, web page publisher 64 and a web user interface 65. Each of these components will be discussed in more detail below. As can be appreciated by one skilled in the art, the decoupling of the target system interface from the monitoring application program advantageously allows for virtually unlimited extensibility of the system 10. To monitor a new target system, a new resource, or a new resource function, the application monitoring program does not need modification. Rather, the target system interface 6 is modified by simply creating a new active server page and/or interface object. • The Transaction Server 60

The transaction sever 60 is a program that runs on the web server 61 and manages transaction requests made by the monitoring application 4. A transaction can be thought of as a sequence of information exchange and related work (such as database updating) that is treated as a unit for the puφoses of satisfying a request and for ensuring database integrity. For a transaction to be completed and database changes to be made permanent, a transaction has to be completed in its entirety. The transaction server screens the user and client computer from having to formulate requests for unfamiliar database and, if necessary, forwards the requests to database servers. It also manages security, connection to other servers, and transaction integrity.

• The Web Server 61

In the preferred embodiment, the web server 61 is the Internet Information Server, which is available from Microsoft Coφoration of Redmond, Washington, and runs on the Windows NT Server or Window 2000 Server operating systems. As is known in the art, the web server 61 is a computer program that serves HTML pages or files requested by the monitoring application 4.

• The ASP Library 62, Interface Objects 63 and Wizards

The target system interface 6 is further comprised of an active server page ("ASP") library 62, which is a collection of resource function test programs, each of which is preferably an ASP. An Active Server Page (ASP) may include HTML code and/or script that are processed on the web server 61 before the HTML code is sent to the monitoring application 4. In some cases, the script uses input received from the monitoring application 4 as parameters to test a resource of the target system 2 and then returns the response received from the target system resource to the monitoring application 4. An ASP file is comprised of either a script written in VBScript, JavaScript or JScript or HTML code.

The active server page library 62 contains the ASP's that are requested by the monitoring application 4. Preferably, each ASP tests a particular resource of the target system 2 in response to a request from the monitoring application 4. An ASP, when requested by the monitoring application 4, may instantiate one or more interface objects 64. The interface objects 64 are discussed in more detail below.

The ASP library 62, and the interface objects 63, and their relationship to the resources of the target system 2 and the monitor 42, are shown in more detail in Figure 33.

As shown in Figure 33, and as discussed above, preferably, a monitor 42 is launched by the monitor supervisor (not shown) and retrieves the information necessary to monitor a target system from the monitor database 43. The monitor 42 is in electronic communication with the monitor database 45. The monitor 42 initiates a resource function test cycle according to the interval options specified via the user interface to the monitoring application and stored in the monitor database 45. Each ASP shown on Figure 33 represents a program to test the various resource functions of the target system 2.

The ODBC ASP and Objects Returning to Figure 33, one of the resources of an exemplary target system is a database 2a. Preferably, the target system database 2a is a database that complies with the Open Database Connectivity ("ODBC") standard. ODBC is an open standard application programming interface (API) for accessing a database. By using ODBC statements in a program, a number of different database files can be accessed, including Microsoft Access, which is available from Microsoft Coφoration of Redmond, Washington, and DB2, which is available from International Business

Machines Coφoration of Armonk, New York.

The monitor 42 tests the target system database 2a by sending a request for a web page, in this example, the ODBC ASP 62a, to the web server (not shown). (The web server is not shown in Figure 33 to simplify the illustration.) Preferably, the request for the web page is sent in either the HTTP protocol or the HTTPS protocol.

HTTPS is a secured form of the HTTP protocol.

The monitor 42 retrieves the information necessary to test the target system database 2a, such as, the name of the web server that will connect to the target system database 2a, the database name and the user ID and password necessary to connect to the database, from the monitor database 45, and sends that information to the web server (not shown) along with the request for the web page (the ODBC ASP 62a) that actually tests the database 2a of the target system. As mentioned above, each ASP includes a script, which executes on the web server (not shown). The ODBC ASP 62a permits the monitor to connect to an external database and to specify activities to monitor. Upon receipt of the request for the ODBC ASP 62a the web server (not shown) begins executing the script included in the ODBC ASP 62a. An exemplary script is set forth below:

On Error Resume Next response .Expires = 0

Set Conn = Server. CreateObject ("ADODB. Connection") Conn.Open Request .QueryString ( "DB" ) , Tri (Request . QueryString ( "UserlD" ) ) ,

Trim (Request .QueryString ( "Password" ) )

If Err.Number = 0 Then

Response. rite ("OK") Else

Response.Write ("Unable to connect to " & Request .QueryString ("DB") & ". " & Err.Description) End If ,

Conn . Close %> The ODBC ASP 62a instantiates an ODBC object 63a. The ODBC object 63a contains the information necessary to test the target system database 2a. The ODBC object 63a, using the information about the target system database 2a received from the monitoring application (not shown), tests the connection to the target system database 2a and receives a response from the target system database 2a. The response is sent by the ODBC object 63a to the web server(not shown), which, in turn, sends the ODBC ASP 62a, with the response information from the target system database 2a, to the monitor 42. The response information is also stored in the monitor database 43. In the preferred embodiment, the same ODBC ASP can be used to test any ODBC compliant database. As mentioned earlier, the system of the present invention also includes several

"wizards," including an ODBC Connection wizard, to facilitate the capture of the information that is passed to the ODBC ASP 62a. Returning to Figure 1 1 , a wizard is activated by selecting the Setup button 110A, which causes the user interface to the wizard selection module to be displayed. From the wizard selection module, which is illustrated in Figure 34, the user can activate the ODBC Connection wizard by selecting the ODBC Connection wizard. An exemplary user interface to the ODBC Connection wizard is illustrated in Figure 35. As can be seen from Figure 35, the information entered by the user via the ODBC Connection wizard includes the name of the web server that will connect to the target system database, the database name and the user ID and password necessary to connect to the target system database, all of which is stored in the monitor database. • The Ping ASP and Objects Returning to Figure 33, another resource of an exemplary target system is a host computer 2b, such as a web server, which can be tested by "pinging" the host computer 2b. A "ping" a basic Internet program that uses the ICMP protocol to verify that a particular IP address exists and can accept requests. It is used diagnostically to ensure that a host computer is actually operating. A Ping program can also be used with a host computer that is operating to see how long it takes to get a response back. A Ping program operates by sending a packet to a designated IP address and waiting for a response.

The monitor 42 retrieves from the monitor database 43 the information necessary to ping the host computer 2b, such as, the name of the web server that will perform the ping, the name of the host computer 2b, and a timeout interval, which is the amount of time the web server performing the ping should wait before determining that the host computer is unavailable, and sends that information to the web server (not shown) along with the request for the web page (the Ping ASP 62b) that is used to ping the host computer 2b. As mentioned above, tine Ping ASP 62b includes a script, which executes on the web server (not shown). The Ping ASP 62b causes the web server (not shown) to ping the host computer 2b. Upon receipt of the request for the Ping ASP 62b, the web server (not shown) begins executing the script included in the Ping ASP 62b. An exemplary Ping ASP 62b script is set forth below: <%

Response. Expires = 0

Response. CacheControl = "Private"

Dim Host

Dim Timeout Host = Request .QueryString ("Host")

Timeout = Request .QueryString ( "Timeout")

If trim (Timeout) = ^»" Then Timeout = 10

Set aPing = Server .CreateObject ( "WCP.WCPPing" ) Response. rite (aping. Ping (Cstr (Host) ,

Cint (Timeout) ) ) Set aOnCall = Nothing

-s>

When the Ping ASP 62b script executes, it instantiates a ping wrapper object 63b, which is data that is put in front of or around the ping object 63c, that provides information about it and may also encapsulate it from view to anyone other than the host computer 2b. A wrapper often consists of a header that precedes the encapsulated data and the trailer that follows it. The wrapper object 63b, in turn instantiates a ping object 63c that actually pings the host computer 2b and receives the response, if any, from the host computer 2b. Preferably, the ping object 63c is the IP Works ICMPPort control, which is available from IP Works, Inc. of Framingham, Massachusetts. The ping request is sent to the host computer using the Internet Control Message Protocol ("ICMP").

The ping object 63c returns the response, if any, obtained from the host computer 2b to the ping wrapper object 63b, including the amount of time, usually in milliseconds, between the sending of the ping and the receipt of the response. The ping wrapper object 63b, in turn, sends the response from the host computer 2b to the web server (not shown), which sends the Ping ASP 62b, which now includes the host computer response, to the monitor 42, using the HTTP protocol. The host computer response is also stored in the monitor database 43. In the preferred embodiment, the same Ping ASP 62b can be used to test any host computer that is connected to an IP network, such as the Internet.

The system of the present invention also includes a ping wizard to facilitate the capture of the information that is passed to the Ping ASP 62b. Upon activation of the ping wizard via the wizard selection module (which is shown in Figure 34), the user interface to the ping wizard, which is illustrated in Figure 36, is displayed. As can be seen from Figure 36, the information entered by the user via the Ping wizard includes the name of the web server that will perform the ping, the name of the host computer, that is, the computer to be "pinged," and a timeout interval, which is the amount of time the web server performing the ping should wait before determining- that the host computer is unavailable, all of which is stored in the monitor database.

• The Telnet ASP's and Objects Returning to Figure 33, the exemplary target system also includes a remote host computer 2c that can communicate in the Telnet protocol. The Telnet protocol . allows access to a host computer, assuming proper permissions have been granted. More specifically, Telnet is a user command and an underlying TCP/IP protocol for accessing a remote host computer. With Telnet, a user can remotely logon on to the remote host computer with whatever privileges that user may have been granted to the specific application and data on the remote host computer.

As shown in Figure 33, preferably, there are multiple Telnet ASP's that are used to test the host computer 2c. For example, there could be a Telnet Logon ASP

62c to log on to the remote host computer and a Telnet Logoff ASP 62e to logoff the remote host computer. There also could be a Telnet PS ASP 62d for getting the process status ("PS") of all jobs running under a particular user ID. The use of separate ASP's to test the various functions (logon, get process status, logoff) of a resource such as the host computer 2c advantageously increases the "granularity" of the monitor. Granularity is the relative level of detail or depth of penetration that the monitor. In other words, the monitor can determine which function of the resource is not operating properly, not just that the resource itself may not be operating properly. For example, to test whether the remote host computer can be logged onto, the monitoring application (not shown) requests the Telnet Logon ASP 62c. The Telnet Logon ASP 62c includes a script, which executes on the web server (not shown), and which causes the web server (not shown) to attempt to log on to the remote host computer 2c. Upon receipt of the request for the Telnet Logon ASP 62c, the web server (not shown) begins executing the script included in the Telnet Logon ASP 62c. In the preferred embodiment, all of the information needed to logon to the host computer using the Telnet protocol is contained in the Telnet Logon ASP 62c. An exemplary Telnet Logon ASP 62c script is set forth below:

Dim Telnetl ProcessRequest EndRequest

Private Sub ProcessRequest () ' On Error Resume Next Response .Expires = 0

Response .CacheControl = "Private"

Timeout = Request .QueryString ( "GabbyTO")

If Timeout = "" Then Timeout = 30

If Not IsNumeric (Timeout) Then Timeout = 30 StartTime = Timer ()

Server . ScriptTimeout = Timeout + 2 Response .Write ("<pre>")

' Instantiate the Telnet Object. This object will be ' saved in the Session Object until persistence is no ¹ longer needed

Set Telnetl = CreateObject ( "WCP.WCPTelnet") If Telnetl .Connect ("nshpk251", "23") Then

Response. rite ("connection OK" & vbCrLf) Else

Response .Write ("could not connect") Exit Sub End If

If not Telnetl. aitForString (chr (0) & "login:", (TimeOut - (Timer () - StartTime))) Then

Response.Write (Telnetl .GetString) Response.Write ("(chr(0) & 'login:') response not received")

Exit Sub End If

Response . rite (Telnetl . GetString)

' Send Userid

Telnetl. send ("wxc0212" & Chr (13)) If not Telnetl. aitForString ("Password: " , (TimeOut - (Timer () - StartTime))) Then

Response.Write (Telnetl .GetString) Response .Write ("('Password:') response not received")

Exit Sub End If Response .Write (Telnetl .GetString) ' Send Password

Telne l. send ("uncblows" & Chr (13))

If not Telnetl.WaitForString (chr (0) & "$", (TimeOut - (Timer () - StartTime))) Then

Response. rite (Telnetl .GetString) Response.Write ("(chr(0) & '$') response not received")

Exit Sub End If Response .Write (Telnetl .GetString)

End Sub

Private Sub EndRequestO

' Save the telnet object in the session variable Set Session ("Telnetl") = Telnetl Response .Write ("</pre>") End Sub

An exemplary Telnet PS ASP 62d script for getting the process status of all jobs running under a particular user ID is set forth below:

Dim Telnetl ProcessRequest EndRequest

Private Sub ProcessReques () ' On Error Resume Next Response.Expires = 0 Response .CacheControl = "Private"

Timeout = Request .QueryString ("GabbyTO") If Timeout = •"' Then Timeout = 30 If Not IsNumeric (Timeout) Then Timeout = 30 StartTime = Timer () Server .ScriptTimeout = Timeout + 2 Response. rite ("<pre>")

¹ Get the Telnet object from the Session variable Set Telnetl = Sessio ("Telnetl")

¹ Get the process status of all jobs running under id Telnetl. send ("ps" & Chr (13)) If not Telnetl.WaitForString ("$", (TimeOut -

(Timer () - StartTime))) Then

Response.Write (Telnetl .GetString) Response.Write ("('$') response not received") Exit Sub End If

Response.Write (Telnetl .GetString)

End Sub Private Sub EndRequestO

' Save the telnet object in the session variable Set Session ("Telnetl") = Telnetl Response .Write ("</pre>") End Sub %>

An exemplary Telnet Logoff ASP 62c script is set forth below:

Dim Telnetl ProcessRequest

EndRequest

Private Sub ProcessRequest () ' On Error Resume Next Response .Expires = 0

Response .CacheControl = "Private"

Timeout = Request .QueryString ( "GabbyTO" )

If Timeout = "" Then Timeout = 30

If Not IsNumeric (Timeout) Then Timeout = 30 StartTime = Timer ()

Server.ScriptTimeout = Timeout + 2 Response .Write ("<pre>")

' Get the Telnet object from the Session variable Set Telnetl = Session ( "Telnetl" )

' logoff

Telnetl. send ("exit" & Chr (13))

If not Telnetl. aitForString ("logout", (TimeOut (Timer () - StartTime))) Then

Response . rite (Telnetl . GetString) Response.Write ("('logout') response not received")

Exit Sub End If

Response .Write (Telnetl .GetString) End Sub Private Sub EndRequestO

' The telnet object is no longer needed, disconnect and

' free the object

Telnetl . Disconnect Set Telnetl = nothing

Set Sessio ("Telnetl") = nothing Session.Abandon Response .Write ("</pre>") End Sub %>

As can be seen from the exemplary scripts set forth above, the Telnet object 63e instantiated by the Telnet Logon ASP 62c persists throughout the Telnet session. For example, when the Telnet Logon ASP 62c script executes, it instantiates a Telnet wrapper object 63d. The Telnet wrapper object 63d, in turn instantiates a Telnet object 63e that actually contains the information necessary to perform the logon test of the remote host computer 2c. Preferably, the Telnet object 63d is the IP Works Telnet control, which is available from IP Works, Inc. of Framingham, Massachusetts. The logon request is sent to the host computer 2c using the Internet Protocol ("IP"). The Telnet object 63e also returns the response obtained from the remote host computer 2c to the telnet wrapper object 63d, such as "Connection OK." The Telnet wrapper object 63d, in turn, sends the response of the remote host computer to the web server, which sends the Telnet Logon ASP 62c, which now includes the remote host computer's response, to the monitor 42, using the HTTP protocol. The host computer response is also stored in the monitor database 43.

The system of the present invention also includes a Telnet wizard to facilitate the generation of a script for a Telnet ASP. Upon activation of the Telnet wizard via the wizard selection module (which is shown in Figure 34), the user interface to the Telnet wizard, which is illustrated in Figure 37, is displayed. Preferably, the user can choose to record or not to record logging on to the remote host computer. In order to record logging on, the Record button 371 is selected prior to logging on. Alternatively, to not record the logon, the user logs on to the resource, and then selects the Record button 371. The Telnet Wizard will then prompt the user to enter the name or IP address of the remote host computer to be monitored. A command screen then appears, and the user can "drive" the resource. By "driving" the resource, I mean actually performing the functions to be monitored on the resource to be monitored. As the user drives the resource, the Telnet Wizard records all of the input to the resource received from the user and all of the responses actually received from the resource in response to the user input. As the user drives the resource and the Telnet Wizard records the user's actions and the resource responses, the Telnet Wizard is automatically generating a script, i.e., an ASP, that will exercise the resource in the same way that the user did via the Telnet wizard. The script may be edited manually in order to make changes to the script automatically generated by the

Telnet wizard. To stop recording the script, the user selects the Stop Recording button 372. Additional scripts can be recorded during a single Telnet session. When the process of recording scripts has been completed, the user interface to the Resource Properties module (see Figure 1 1) is displayed, and the Description and URL fields have been populated with appropriate information based on the actions taken by the user. In addition, the Response field is populated with the first ten characters (including spaces) that appeared on the user interface to the Telnet wizard. Preferably, when the user finishes driving the resource (i.e., the Stop Recording button 372 is selected), the Telnet Wizard has completed the process of automatically generating an ASP, which then can be used immediately in monitoring the resource. • The Terminal Emulation ASP's and Objects Returning to Figure 33, the exemplary target system also includes a mainframe computer 2d, such as a IBM S/390 running the IBM Customer Information Control System (CICS), both of which are available from International Business Machines Coφoration of Armonk, New York.

As shown in Figure 33, preferably, there are multiple Terminal Emulation ASP's that are used to test the host computer 2d. For example, there could be a Terminal Emulation Logon ASP 62f to log on to the mainframe computer and a Terminal Emulation Logoff ASP 62h to logoff the mainframe computer. There also could be a Terminal Emulation CEMT ASP 62d for executing a CEMT transaction.

A CEMT transaction is a CICS-supplied transaction that invokes all the master terminal functions, such as inquiring and changing the value of parameters used by CICS, altering the status of system resources, terminating tasks, and shutting down CICS. As mentioned earlier, the use of separate ASP's to test the various functions (logon, CEMT transaction, logoff) of a resource such as the mainframe computer 2d advantageously increases the "granularity" of the monitor.

For example, to test whether the mainframe computer 2d can be logged onto, the monitoring application (not shown) requests the Terminal Emulation Logon ASP 62f. The Terminal Emulation Logon ASP 62f includes a script, which executes on the web server (not shown), which causes the web server (not shown) to attempt to log on to the mainframe computer 2d. Upon receipt of the request for the Terminal Emulation Logon ASP 62f, the web server (not shown) begins executing the script included in the Terminal Emulation Logon ASP 62f. In the preferred embodiment, all of the information needed to logon to the mainframe computer 2d using the TN3270 protocol is contained in the Terminal Emulation Logon ASP 62f. An exemplary Terminal Emulation Logon ASP 62f script is set forth below:

Public MyAviva Public MySession Public MyPS

Public re Public Timeout Public StartTime ProcessRequest Disconnect

Private Sub ProcessRequest () ' On Error Resume Next Response. Expires = 0

Response. Write ("<hr>")

Timeout = Request . QueryString ("GabbyTO") If Timeout = "" Then Timeout = 30 If Not IsNu eric (Timeout) Then Timeout = 30 StartTime = Timer () - 0.4 Server . ScriptTimeout = Timeout

' Create the Aviva Application object and save it in a ' Session Variable

Set MyAviva = CreateObject ( "Aviva .Application") If MyAviva is Nothing Then

Response. Write ("Aviva Object not instantiated. ") Exit Sub

End If Set Session ("MyAviva") = MyAviva

' Create the Aviva Session object and save it in a ' Session Variable

Set MySession = MyAviva. Sessions .Add ( "IBMWEC.a3d" , False)

If MySession is Nothing Then

Response. rite ("Aviva Session Object not instantiated. LastError=" & MyAviva.LastError) Exit Sub End If Set Session ("MySession") = MySession re = MySession. SetSharing (3) re = MySession. Connect (True) Set MyPS = MySession.PS

' Please verify that the following string is unique rc = MyPS. aitForString ("THIS IS A SECURED NETWORK, IT IS UNLAWFUL TO ACCESS THIS NETWORK", 2, 1, (TimeOut - (Timer () - StartTime)) * 1000) If rc <> 0 Then

Response. rite ("Expected Response (THIS IS A SECURED NETWORK, IT IS UNLAWFUL TO ACCESS THIS NETWORK) Not Received rc=" & rc) DisplayScreen Exit Sub

End If DisplayScreen

' connect to cicsq4 MyPS.SetData "cicsq4", 9, 48 MyPS . Sendstring "{enter}"

' Please verify that the following string is unique

1 rc = MyPS.WaitForString ("SYSTEM:", 2, 8, (TimeOut - (Timer () - StartTime)) * 1000) If rc <> 0 Then

Response. rite ("Expected Response (SYSTEM:) Not Received rc=" & rc) DisplayScreen

Exit Sub End If DisplayScreen ' logon with userid and password MyPS.SetData "wxc0212", 12, 21 MyPS.SetData "uncblows" , 13, 21 MyPS.SendString "{enter}" ^τ Please verify that the following string is unique rc = MyPS. aitForString ("ACFAE199 ACF2/CICS SIGN-ON COMPLETE", 6, 1, (TimeOut - (Timer () - StartTime)) * 1000) If rc <> 0 Then

Response. Write ("Expected Response (ACFAE199 ACF2/CICS SIGN-ON COMPLETE) Not Received rc=" & rc) DisplayScreen Exit Sub End If

DisplayScreen

Send the Clear Key to the Host MyPS.SendString "{clear}"

Please verify that the following string is unique rc = MyPS.WaitForString (" ", 1, 1, (TimeOut - (TimerO - StartTime)) * 1000) If rc <> 0 Then Response. rite ("Expected Response ( ) Not

Received rc=" & rc)

DisplayScreen Exit Sub End If DisplayScreen End Sub

Private Sub DisplayScreen ()

ScreenData = MyPS.GetData ScreenPos = 1

Response. Write ("<pre>") For i = 1 To 24

Response.Write (Mid (ScreenData, ScreenPos, 80) & vbCrLf) ScreenPos = ScreenPos + 80

%>

An exemplary Terminal Emulation CEMT ASP 62fgscript is set forth below:

Public MyAviva Public MySession Public MyPS

Public rc Public Timeout Public StartTime ProcessRequest

Disconnect

Private Sub ProcessRequest ( ) ' On Error Resume Next Response . Expires = 0

Response . rite ( " <hr> " )

Timeout = Request . QueryString ( "GabbyTO" ) If Timeout = " " Then Timeout = 30 If Not IsNumeric (Timeout) Then Timeout = 30 StartTime = Timer () - 0.4 Server .ScriptTimeout = Timeout

' Get saved Aviva Application Object from Session ' variable

Set MyAviva = Session ("MyAviva") If MyAviva is Nothing Then Response.Write ("Aviva Object not instantiate . " )

Exit Sub End If ' Get the saved Aviva Application Session from the ' Session variable

Set MySession = Session ("MySession") If MySession is Nothing Then

Response.Write ("Aviva Session Object not instantiated. LastError=" & MyAviva. astError) Exit Sub End If If MySession. ConnectionState <> 4 Then

Response.Write ("Not Connected to Host") Exit Sub

End If Set MyPS = MySession.PS

' Run the CEMT I TAS transaction MyPS.SetData "ce t i tas", 1, 1 MyPS.SendString "{enter}"

' Please verify that the following string is unique rc = MyPS.WaitForString ("I TAS", 1, 3, (TimeOut -

(Timer () - StartTime)) * 1000) If rc <> 0 Then

Response.Write ("Expected Response (I TAS) Not Received rc=" & rc) DisplayScreen

Exit Sub End If DisplayScreen ' Send pf3 to the Host

MyPS.SendString "{pf3}"

' Please verify that the following string is unique rc = MyPS. aitForString ("STATUS:", 2, 3, (TimeOut - (Timer () - StartTime)) * 1000) If rc <> 0 Then

Response.Write ("Expected Response (STATUS:) ot Received rc=" & rc) DisplayScreen Exit Sub

End If DisplayScreen

' Send the Clear Key to the Host MyPS.SendString "{clear}"

' Please verify that the following string is unique rc = MyPS.WaitForString (" ", 1, 1, (TimeOut - (Timer () - StartTime)) * 1000) If rc <> 0 Then

Response. Write ("Expected Response ( ) Not Received rc=" & rc)

DisplayScreen Exit Sub

End If DisplayScreen

End Sub

Private Sub DisplayScreen ()

ScreenData = MyPS.GetData ScreenPos = 1 Response .Write ("<pre>") For i = 1 To 24

Response .Write (Mid (ScreenData, ScreenPos, 80) & vbCrLf)

ScreenPos = ScreenPos + 80 Next Response .Write ( "</prexhr>" ) End Sub

Private Sub Disconnect ()

On Error Resume Next ^{' :} End Sub %>

An exemplary Terminal Emulation Logoff ASP 62h script is set forth below:

Public MyAviva

Public MySession Public MyPS Public rc Public Timeout Public StartTime

ProcessRequest Disconnect

Private Sub ProcessRequest () • On Error Resume Next

Response. Expires = 0

Response.Write ("<hr>")

Timeout = Request .QueryString ("GabbyTO") If Timeout = "" Then Timeout = 30 If Not IsNumeric (Timeout) Then Timeout = 30 StartTime = Timer () - 0.4 Server .ScriptTimeout = Timeout

' Get the saved Aviva Application Object from the Session ' variable Set MyAviva = Session ( "MyAviva") If MyAviva is Nothing Then

Response .Write ("Aviva Object not instantiated. ")

Exit Sub End If

' Get the saved Aviva Application Session from the ' Session variable

Set MySession = Session ( "MySession" ) If MySession is Nothing Then

Response .Write ("Aviva Session Object not instantiated. LastError=" & MyAviva .LastError) Exit Sub End If If MySession. ConnectionState <> 4 Then

Response .Write ("Not Connected to Host") Exit Sub End If Set MyPS = MySession.PS

MyPS.SetData "logoff", 1, 1 MyPS.SendString "{enter}"

' Please verify that the following string is unique rc = MyPS. WaitForString ("THIS IS A SECURED NETWORK, IT IS UNLAWFUL TO ACCESS THIS NETWORK", 2, 1, (TimeOut - (Timer () - StartTime)) * 1000)

If rc <> 0 Then Response.Write ("Expected Response (THIS IS A SECURED NETWORK, IT IS UNLAWFUL TO ACCESS THIS NETWORK) Not Received rc=" & rc) DisplayScreen Exit Sub End If DisplayScreen

End Sub

Private Sub DisplayScreen ()

Response.Write (Mid (ScreenData, ScreenPos, 80) & vbCrLf)

ScreenPos = ScreenPos + 80 Next Response .Write ("</pre><hr>" ) End Sub

Private Sub Disconnect ()

¹ Disconnect and free the Aviva Objects. Persistence is

' no longer needed

On Error Resume Next rc = MySession.Disconnect rc = MySession. Close Set MyPS = Nothing

Set MySession = Nothing Set MyAviva = Nothing Set Session ( "MySession") = Nothing Set Session ("MyAviva") = Nothing End Sub

As can be seen from the exemplary scripts set forth above, the Terminal ^' Emulation object 63f instantiated by the Terminal Emulation Logon ASP 62f persists throughout the Terminal Emulation session. For example, when the Terminal

Emulation Logon ASP 62f script executes, it instantiates a Terminal Emulation object 63f that actually contains the information necessary to perform the logon test of the mainframe computer 2d.

The Terminal Emulation object 63f is preferably a TN3270 object and is Distributed Component Object Model ("DCOM") object. Distributed Component Object Model is a set of concepts and program interfaces developed by Microsoft Coφoration of Redmond, Washington, in which client program objects can request services from server program objects on other computers in a network. DCOM is based on the Component Object Model (COM), which provides a set of interfaces allowing clients and servers to communicate within the same computer. In the preferred embodiment, the TN3270 object used can be obtained from Aviva Solutions, Inc. of Montreal, Canada, and is included with the Aviva For Desktops TN3270 terminal emulation platform. The Terminal Emulation object 63f also receives the response obtained from the mainframe computer 2d, such as "CICS SIGN-ON COMPLETE." The Terminal Emulation object 63f, in mm, sends the response of the mainframe 2d computer to the web server (not shown), which sends it to the Terminal Emulation Logon ASP 62f. The Terminal Emulation Logon ASP 62f now includes the mainframe computer's response and sends it to the monitor 42 using the HTTP protocol. The mainframe computers response is also stored in the monitor database 43.

Returning to Figure 33, as can be appreciated by one skilled in the art, the exemplary target system also may include a microcomputer, such as an AS/400, which is available from Internationa] Business Machines Coφoration of Armonk, New York, rather than a mainframe computer. The microcomputer can be tested in essentially the same fashion as the mainframe computer 2d, as described above, using a TN5250 object rather than a TN3270 object. In the preferred embodiment, the TN5250 object used can be obtained from Aviva Solutions, Inc. of Montreal, Canada, and is included with the Aviva For Desktops TN5250 terminal emulation platform. The system of the present invention also includes a TN3270 wizard to facilitate the generation of a script for a Terminal Emulation ASP, such as a TN3270 ASP. Upon activation of the TN 3270 wizard via the wizard selection module (which is shown in Figure 34), the user interface to the TN 3270 wizard is displayed. The user interface to the TN3270 wizard, and the method of automatically generating a script for a TN3270 ASP, is essentially that same as that for the Telnet wizard, which is discussed above.

• The Event Log ASP and Objects Returning to Figure 33, the exemplary target system also may include an event log 2e, such as a Windows NT Event log, which is included in the Windows NT operating system, which is available from Microsoft Coφoration of Redmond,

Washington. In the Windows NT operating system, an event is any significant occurrence in the system or in an application that requires a user to be notified. For critical events, such as a full server or an interrupted power supply, a message may be displayed. For many other events that do not require immediate attention, the Windows NT operating system adds information to an event-log file to provide information without displaying a message about the event. An event logging service typically starts automatically when a computer running the Windows NT operating system is started.

Typically, the event log is comprised of a system log, a security log and an application log. The system log records events logged by the operating system components. For example, the failure of a driver or other system component to load during startup is recorded in the system log. The security log records security events, which helps track changes to the security system and identify any possible breaches to security. For example, attempts to log on the system may be recorded in the security log. The application log records events logged by applications. For example, a database application might record a file error in the application log.

Returning to Figure 33, the monitor 42 retrieves the information necessary to monitor the event log 2e, such as, the name of the web server that will check the event log, the type of log to be checked, system, security or application, and the age of the log to be checked, from the monitor database 43, and sends that information to the web server (not shown) along with the request for the web page (the Event Log ASP 62e) that actually checks the target system event log 2e. Additional information relevant to checking an event log can be stored in the monitor database 45, such as, the name of the computer upon which the event log is stored, the source of the event, and event ID and an event type.

As mentioned above, the Event Log ASP 62e includes a script, which executes on the web server (not shown). The Event Log ASP 62e permits the monitor 42 to connect to the computer upon which the event log is stored to determine if a specified event has occurred. Upon receipt of the request for the Event Log ASP 62e the web server (not shown) begins executing the script included in the Event Log ASP 62e.

An exemplary script is set forth below:

<% set aEventLog = Server. GreateObject ( " CP.WCPEventLog" ) Response.expires = 0

Response.Write (Request .QueryString ( "ComputerName" ) & _

Request .QueryString ("Log" ) &_ Request .QueryString ( "SourceName" ) &

Request .QueryString ( "EventId") & _ Request .QueryString ( "EventType") & Request .QueryString ( "SecondsOld" ) ) Response .Write (aEventLog . CheckEventLog

Request .QueryString ("ComputerName") ,_

Request .QueryString ( "Log") , _ Request .QueryString ("SourceName" ) , Request .QueryString ( "Eventld") , ___ Request . QueryString ( "Event ype" ) , _ Request - QueryString ( "SecondsOld" ) ) ) set aEventLog = Nothing %> As can be seen from the script set forth above, the Event Log ASP 62e instantiates an EventLog object 63g, which contains the information necessary to check the event log 2e.

The EventLog object 63 g, using the information about the event log 2e received from the monitoring application (not shown), checks the event log 2e and receives a response from the event log 2e. The response is sent by the EventLog object 63 g to the web server (not shown), which, in turn, sends the Event Log ASP 62e to the monitor 42. The response information is also stored in the monitor database 43.

The system of the present invention also includes an event log wizard to facilitate the capture of the information that is passed to the Event Log ASP 62e.

Upon activation of the event log wizard via the wizard selection module (which is shown in Figure 34), the user interface to the event log wizard, which is illustrated in Figure 38, is displayed. As discussed above, the Event Log ASP 62e is a predefined and receives information stored in monitor database 43 that is necessary to check an event log for a particular resource. The information captured by the event log wizard includes the name of the web server that will check the event log 381 , the type of log to be checked 382, that is a system, security or application event, and the age of the log to be checked 383. Additional information relevant to checking an event log can be captured by the event log wizard includes the name of the computer upon which the event log is stored, the source of the event, and event ID and an event type.

Returning to Figure 33, the target system also may include a web site 2f. It should be noted that a web site can be tested directly by the monitoring application, that is, the resource function test request is not sent via the target system interface, because the monitoring application is capable of sending requests in the HTTP protocol, which is the protocol understood by a web server.

The system of the present invention includes an Internet browser wizard, which automatically captures the data necessary to test a function on a web site 2f.

When the Internet browser wizard is activated via the wizard selection module (which is shown in Figure 34), the user interface to the Internet browser wizard, which is illustrated in Figure 39, is displayed. As shown in Figure 39, the user is presented with an interface that includes a recorder 391 and an Internet browser 392. Preferably, the Internet browser 392 is the Internet Explorer, which is available from

Microsoft Coφoration of Redmond, Washington. In operation, the user selects the Record button 393, which puts the Internet browser wizard in a record mode. The user then "exercises" the web site by using the Internet browser 392 in a conventional manner. While the Internet browser wizard is in record mode, all of the actions by the user and the responses from the web site are recorded until the user selects the Stop

Recrdng button 394, which takes the Internet browser out of record mode. If the user selects the Submit button 395, the URL and Post Data fields of are automatically populated with the information recorded by the Internet Explorer wizard.

As can be appreciated by one skilled in the art, a wizard can be created to simplify, and increase the efficiency of the process of, creating an ASP for testing a target system resource and/or a target system resource function.

• The Web Page Publisher 64

The web page publisher 64 publishes a web page that displays the status of each target system being monitored, which can be viewed via the web-based user interface 65, which discussed in more detail below. Preferably, the web page publisher 64 publishes a monitor summary page, which is a web page that displays the target system diagrams for all target systems being monitored, immediately upon completion of the resource function test sequence for each resource of each target system being monitored. The monitor summary page is discussed in more detail below.

The web page publisher 64 also publishes an alerts page, which is a web page that displays the target system diagram for all target systems being monitored wherein an error was detected with respect to one or more of the resources of a target system. Preferably, the alerts page is published immediately upon completion of the resource function test sequence during which the error was detected. The alerts page is discussed in more detail below.

In addition, the web page publisher also publishes a separate monitor results page for each target system being monitored, preferably, upon completion of all resource function test sequences of the target system. The monitor results page is discussed in more detail below.

• The Web-based User Interface 65

Returning to Figure 2, the system 10 of the present invention includes a web- based user interface 65. This interface 65 provides detailed information on monitors 42 that have been created and have been launched by the monitor supervisor 41. The interface 65 permits a user to view monitor results, view summary reports, maintain on call schedules, page specific employees or application groups, specify e-mail and pager notifications, and view the results of all monitors actively running. For security, user name and password may be required in order to access the web-based user interface. • Viewing all Active Monitors As shown in Figure 40, the web-based interface displays a monitor summary page, which shows the target system diagrams for all of the active monitors. As mentioned above, the web page publisher (not shown) publishes a monitor summary page for all active monitors immediately upon the completion of a. resource function test sequence. Alternatively, the web page publisher publishes a monitor summary page immediately upon completion of the resource function test sequence for all resources of a target system.

Preferably, the monitor summary page is an active server page and can be thought of as the "home page" of the web-based user interface. In order for a target system monitor to be displayed on the monitor summary page 400,the Include On

Web Home Page checkbox must be selected for the monitor via the General Options folder, as discussed above. The target system diagrams are discussed in more detail below.

From the monitor summary page, an Alerts page can be accessed, which displays the target system diagram of the monitors that currently have an enor and that have been designated to be displayed on the Alerts page by selecting the Include On Alerts Page check box via General Options folder of the Resource Properties module. Preferably, the Alerts page is access by selecting the link entitled Alerts 401 via the monitor summary page 400. • Viewing a Specific Monitor

Returning to Figure 40, to view more detailed information about a specific monitor, the target system diagram for the monitor is selected via the monitor summary page 400, which will cause the monitor results page for the selected monitor to be displayed, as shown in Figure 41. The monitor results page 410 provides detailed information as to the performance of a particular target system during testing. As shown in Figure 410, the monitor results pages contains three sections: a color- coded target system diagram 411, which represents the status of each resource that was tested; a response time graph 412, which graphically represents the length of time that elapsed between the call to the resource and its response over a set period of time; and an error log420 (shown on figure 42), which lists the errors that have occurred and the pages and/or e-mails sent.

• Target System Diagram

Figures 40 and 41 illustrate an exemplary the target system diagram 402, 411, which displays the various resources of the target system as blocks and the relationships between the resources. Preferably, each block is color coded in order to provide a visual indication of the status of the resource represented by the block. For example, if the block is green, the resource is operating correctly. In other words, no error was returned when the resource was last tested. If the block is yellow, the resource is not functioning conectly, although the eiror will not prevent the system from testing other functions performed by that resource. If the block is red, the resource is not functioning correctly, and the error is critical. In other words, the resource will not be able to perform any other functions until the error is corrected. If the block is dark blue, the resource is currently being tested. If the block is light blue, the resource is not currently being tested. Typically, resource is not being tested because an error has occurred on a related resource or because the resource has not been scheduled for testing. If the block is gray, the resource has been disabled so that it will not be tested. While colors are desired for visual display, shading or other symbols may also be used to depict the same conditions.

• Response Time Graph As shown in Figure 41, the response time graph 412 is included on the monitor results page. Preferably, the response time graph is color coded The color- coded response time gTaph 412 displays information about the length of time that elapsed between a call to a resource and its response over a set period of time. Each line on the graph 412 represents an individual resource; all of these resources together constitute the target system being monitored. Preferably, the lines on graph 412 are represented in different colors to differentiate the lines from each other. Preferably, as illustrated in Figure 42, also included on the monitor results page is a response times listing 420. The response times listing 420 includes information about the resource name, response time, and the description of the resource. The background color of the response time corresponds to the resource's color on the response time graph 412. The specific response provided by the resource can be accessed by selecting the resource description 421. The error message can be edited by selecting on the error message 422 , which causes the system to display the modify enor message information module. Figure 43 illustrates the interface to the modify error message information module 430.

• Error Log As shown in Figure 44, the enor log 440 lists the errors that have occurred during some predetermined period of time, e.g., the past two days. Preferably, after some predetermined time, e.g., 12:00 noon, the previous day's errors are removed from the list. Error logs are purged based upon the settings specified via monitor supervisor, which is discuss above. The error log 440 lists the resource 441, the description 442, time of error 443, and response 444. The resource itself can be displayed by selecting the description 442. • Specifying On call Groups/Employees The system of the present invention provides an On Call module, which can be accessed via the web-based user interface. Returning to Figure 40, to activate the On Call module, the On Call link 403 is selected, which causes the interface to the On Call module to be displayed. The interface to the On-Call module is illustrated in Figure 45. As can be seen in Figure 45, the On-Call module allows a user to page an employee 451, page an application's employees 452, add a new on call employee 453, modify employee information 454, view employee schedules 455, add a new application group 456, modify application groups 457, and view application group on call schedules 458. The information entered via the On-Call module is stored in the On-Call database, which is discussed in more detail above.

Returning to Figure 45, to page an employee, or other technical support personnel, the Page An Employee 451 link is selected under Paging Options 450A, which will cause the Page An Employee web page to appear. The Page An Employee web page is illustrated in Figure 46. The employee to be paged is selected from the Employee drop down box 461. The appropriate page number is entered into the digital page field 462. The text of the page is entered in the text page 463 field. As characters are entered into the text page field 463, the value in the page length field 464 will change accordingly. To send the page, the Send Page button 465 is selected. Returning to Figure 45, to page all of the employees, i.e., technical support personnel, associated with a particular target system, or application, the Page An

Application Group's On-Call Employees link 452 is selected, which will cause the Page An Application Group's On-Call Employees web page to be displayed. The Page An Application Group's On-Call Employees web page is illustrated in Figure 47. The employee group to be paged is selected from the Group drop down box 471. The type of group can be selected from the Support Level drop down box 472. The appropriate page number is entered into the digital page field 473. The text of the page is entered in the text page 474 field. As characters are entered into the text page field 474, the value in the page length field 475 change accordingly. To send the page, the Send Page button 476 selected. Returning to Figure 45, to add a new employee to the On-Call module, the

Add a New Employee link 453 is selected, which will cause the Add a New Employee web page to be displayed. The Add a New Employee web page is illustrated in Figure 48. Once a new employee is added via the Add a New Employee web page, the employee's information is stored in the On-Call database and the employee can be schedule to receive pages or e-mail messages. Information should be entered into the following fields displayed via the Add New Employee web page:

Employee ID field

Employee Name field

E-mail address field (optional) Work Phone Number field (optional)

Home Phone Number field (optional)

Pager Phone Number field (optional)

Pager E-Mail Address field (optional)

Paging Provider drop-down list Paging Pin Number field

Alpha Modem Number (Pagenet) field.

Suppress New Pages Interval field - the number of minutes that must elapse between pages from the same monitor

Repage When Available check box - select to page the employee again after the number of minutes entered in the Suppress New Pages Interval field have elapsed. To add the employee select the Submit button, which will cause the interface to the On-Call System to be displayed.

Returning to Figure 45, to modify employee information, the employee whose information is to be modified is selected from the Employee drop-down box 453A, and the Modify Employee Information link 454 is selected, which will cause Modify

Employee Information web page to be displayed. The Modify Employee Information web page is illustrated in Figure 49. Once employee information is modified via the Modify Employee Information web page, the employee's information is stored in the On-Call database and the employee can be scheduled to receive pages or e-mail messages. As can be seen in Figure 49, the fields of information displayed and that are modifiable via the Modify Employee Information web page are the same as the fields displayed and into which information is entered via the Add a New Employee web page. The modified employee information is saved to the On-Call database by selecting the Change button 491. Preferably, the employee selected via the Employee drop down box can be deleted from the On-Call database by selecting the Delete button 491.

Returning to Figure 45, an employee's on call schedule can be viewed by selecting the employee via the Employee drop-down box 453A, and then selecting the View Employee On-Call Schedule Report link 455, which will cause the on call schedules for the selected employee for four (4) months, including the current month and the three months following the current month, to be displayed. An exemplary employee on call schedule is illustrated in Figure 50. The numbers listed beside the person to be paged indicates the level of technical support to be provided, e.g., primary, secondary, tertiary, Level 4 and Level 5. Preferably, primary technical support personnel are paged first, secondary technical support personnel are paged second, and so on.

Returning to Figure 45, a new application group can be added to an on call schedule by selecting the Add New Application group link 456, which will cause the Add an Application web page to be displayed. The Add an Application web page is illustrated in Figure 51. An application group can be though of as the resources which comprise a target system. Preston, is this correct? The application's identification number is entered into the Application ID field 511 and the name of the application is entered into the Application Name field 512. The application group information is saved to the On-Call database by selecting the Submit button 513. Returning to Figure 45, to modify application group information, the application group is selected from the Application Group drop-down box 457A, and the Modify an Application Group link 457 is selected, which will cause the Modify an Application Group web page to be displayed. The Modify an Application Group web page is illustrated in Figure 52. Once application group information is modified via the Modify Application Group web page, the application group information is stored in the On-Call database. As can be seen in Figure 52, the fields of information displayed and that are modifiable via the Modify an Application Group web page are the same as the fields displayed and into which information is entered via the Add an Application Group web page. The modified application group information is saved to the On-Call database by selecting the Change button 521. Preferably, the application group selected via the Application Group drop down box can be deleted from the On- Call database by selecting the Delete button 522

Returning to Figure 45, an application group's on call schedule to be created or modified by selecting the application group from the Application Group drop-down box 457A, and selecting the Modify an Application's On-Call Schedule link 458, which will cause the On-Call Schedule web page to be displayed for the selected application group. The On-Call Schedule web page is illustrated in Figure 53. The employee to be paged in the event of an error is selected via the Employee drop down box 531. The range of dates during which the employee will be paged can be changed by entering the start date in the From Date field 532 and the end date in the

To Date field 533. The time frame when the employee will be paged can be changed by entering the start time in the From Time field 534 and the end time in the To Time field 535. The level of the page the employee will receive can be changed by selecting an option from the Level drop-down box 536. As discussed above, the paging levels are primary, secondary, tertiary, Level 4, Level 5, and 2-way pager. The

2-way pager option works in conjunction with the Motorola Page Writer 2000x, which is available from Motorola Coφoration of Schaumburg, Illinois. Preferably, the page includes a log of the errors that have occurred. The on call schedule for the application group information is saved to the On Call database by selecting the Submit button 537.

Returning to Figure 45, an application group's on call schedule can be viewed by selecting the application group via the Application Group drop-down box 457A, and then selecting the View Application On-Call Schedule Report link 459, which will cause the on call schedule for the selected application group for four (4) months, including the current month and the three months following the current month, to be displayed. An exemplary application group on call schedule is illustrated in Figure 54. The numbers listed beside the person to be paged indicates the level of technical support to be provided, e.g., primary, secondary, tertiary, Level 4 and Level 5. Preferably, primary technical support personnel are paged first, secondary technical support personnel are paged second, and so on. • The On Call Database Returning to Figure 2, the monitor application 4 also includes an on call database, which stores information needed by the notification interface 45 to notify technical support personnel, or other computer systems, in the event of an error in a resource function of a target system being monitored. As can be appreciated by those skilled in the art, the information stored in the on call database can be stored in the same database as the information contained in the monitor database 43. Preferably, however, the information stored in the on call database and the monitor database is stored in separate databases. Generally, the information on the on call database is entered and modified via the web-based user interface, which is discussed in more detail below. In the preferred embodiment, the on call database is a relational database and is creating using a commercially available database management program, such as Microsoft Access, which is available from Microsoft Corporation of Redmond, Washington. Returning to Figure 45, information for the employee table, shown as Figure

55, may be entered by selecting the Add a New Employee link. The employee table 550 in Figure 55 contains the following fields of information:

EmployeelD — indicates a unique employee identifier assigned by the employer. EmployeeName - given name of the employee.

WorkPhoneNumber, HomePhoneNumber, PagerPhoneNumber- indicates the contact numbers for the employee.

PagerEmailAddress, EmailAddresses-the employee-unique addresses for e- mail notifications. Figure 56 is illustrative of a call schedule table 560 for a particular employee. This table provides on call schedule information for a specified period and the level of technical response required. The table contains the following fields of information:

Group Key - a numberical identifier assigned to an application group

GroupID - indicates the particular group identification for an application Support Level - indicates the level of technical response to a specified resource response.

FromDate - the date that the particular employee begins on call responsibility.

FromTime - indicates the time of day that the employee begins on call responsibility. ToDate - indicates the date that the particular employee's on call responsibility ends.

ToTime - indicates the time of day that the employee's on call responsibility ends.

EmployeelD — specifies the unique identification assigned to a particular employee.

Figure 57 is illustrative of a paging provider table 570 listing all of the possible paging providers that may provide paging service for employees. This nble contains the following fields of information:

Paging Provider - indicates the name of the provider. URL - specifies the HTTP path for the given provider.

PostData - specifies any post data that should be include with the URL

Anticipated Response - indicates the response that is expected when the paging provider receives and/or delivers the message.

MaxMsg- the value in this field indicates the maximum message length in number of characters Also included in the On Call Database is the ContactLog table 580, shown as Figure 58. This table provides details of employee contacts made by the system. The ContactLog table contains the following fields of information: LogID - the identifier assigned to the particular log LogStatus — Preston?

LogDate - the date that the system contacted an employee LogTime — the time of day that the system contacted an employee EmployeelD — the identification of the employee who was contacted MonitorName — the application monitor associated with the employee contact Log Text - the message sent to the employee contact

Also included in the On Call Database is the Groups table 590, shown as Figure 59. This table identifies which group by name is associated with a particular group identification. The Groups table contains the following fields of information: GroupID — the identifier assigned to a particular group GroupName — the name of the group associated with the group identifier

• Viewing and Modifying Application Configurations The system of the present invention provides a Configurations module, which can be accessed via the web-based user interface. The Configurations module allows a user to select an application, i.e., target system. Once the application has been selected, a user can view or edit the settings, i.e., configurations for the selected application, such as testing intervals, support levels that are sent an e-mail message or page, and the details of a resource, such as, the resource functions, timeout setthgs, and pager and e-mail settings. As discussed below, a target system's monitor configuration can be changed via the Configurations module. Returning to Figure 40, to activate the Configurations module, the Configurations link 404 is selected, which causes the Application Selection web page to be displayed. The Application Selection web page is illustrated in Figure 60. As can be seen in Figure 60, an application is selected by selecting the application in the Application drop-down box 601 and selecting the Review Application Configurations link 602, which will cause the Monitor Configuration web page to be displayed. The

Monitor Configuration web page is illustrated in Figure 61. As shown in Figure 61 , the current monitoring configurations for the selected application are displayed, such as testing and error retesting interval information and pager support levels information. In addition, each resource of the application, i.e., target system, is displayed in the Resource section 611, along with the function description in the

Function Description section 612. A group can be added to or deleted from the pager list and an employee can be added to or deleted from the e-mail list via the Function Description section 612. Information about when the resource function times out is displayed in the TimeOut section 613. • Monitor Reports

The system of the present invention includes a Reports module that conveniently generates summary reports for each target system and resource that is being monitored. Such reports can provide information on resource availability, average response times, and errors, which can be useful in making business decisions, such as determining if a resource's or target system's availability is within acceptable parameters.

Returning to Figure 40, to activate the Reports module, the Reports link 405 is selected, which causes the interface to the Reports module to be displayed. The interface to the Reports module is illustrated in Figure 62. As can be seen in Figure 62, the Reports module allows a userto view resource reports, including Availability by Resource. Average Response Times by Resource and Average Response Times by Resource Function. The resource reports provide only the information that relates to an individual resource, not to an entire application, i.e., target system, being monitored. The Reports module also allows a user to review application, i.e., target system, reports, including, Availability by Application, Retrieve Old Application Log, and Customer Experience Report.

• Resource Reports Returning to Figure 62, before accessing a resource report, the resource must be selected via the resource drop-down box 621. To access the Availability by Resource report the Availability by Resource link 622 is selected, which will display the Availability by Resource report. An exemplary Availability by Resource report is illustrated in Figure 63. As shown in Figure 63, the Availability by Resource report provides information about the number of minutes the selected resource has been "up" (accessible) or "down" (not accessible) for each day during the previous month and total up time and down time for the current month, all of which is displayed in a calendar format. Preferably, the Availability by Resource report is color coded to indicate whether the applicable service level agreement has been complied with for a particular day during which the resource is monitored. The service level agreement information is entered via the service level agreement options folder, which is discussed above. For example, if resource is available on a particular day less than 98% of the monitoring time period, the day is displayed in the color yellow. Similarly, if resource is available on a particular day less than 96% of the monitoring time period, the day is displayed in the color red. If the resource availability is within the parameters defined via the service level agreement options folder, then the day is not displayed in color. Preferably, days during which the resource is not monitored are displayed in the color gray. Also, it is preferable that if the resource availability is 100% during the previous month and current month, a message so indicating would be displayed, and the Availability by Resource report would not be displayed. In other words, the Availability by Resource report is displayed if the resource availability for the relevant time period is less than

100%.

A resource error log for a particular day can be displayed by selecting that day from the calendar displayed in the Availability by Resource report. Figure 64 is an illustrative resource error log. Returning to Figure 62, to access the Average Response Times by Resource report the Average Response Times by Resource link 623 is selected, which will display the Average Response Times by Resource report. An exemplary Average Response Times by Resource report is illustrated in Figure 65. As shown in Figure 65, Average Response Times by Resource report displays in a chart format the average response times of the selected resource over the past 30 days.

Returning to Figure 62, to access the Average Response Times by Resource Function report the Average Response Times by Resource Function link 624 is selected, which will display the Reporting System web page. The Reporting System web page is illustrated in Figure 66. As shown in Figure 66, to select a particular function for the selected resource, the resource function is selected via the Resource

Function drop down box 661 and the Average Response Times by Function for [selected resource] link 662 is selected, which will cause the Average Response Times by Resource Function report to be displayed. An exemplary Average Response Times by Resource Function report is illustrated in Figure 67. As shown in Figure 67, Average Response Times by Resource Function report displays in a chart format the average response times of the selected resource function overthe past 30 days.

• Target System Reports Returning to Figure 62, before accessing an application (i.e., target system) report, the application must be selected via the application drop-down box 625. To access the Availability by Application report the Availability by Application link 626 is selected, which will display the Availability by Application report. An exemplary Availability by Application report is illustrated in Figure 68. As shown in Figure 68, the Availability by Application report provides information about the number of minutes the selected application has been "up" (accessible) or "down" (not accessible) for each day during the previous month and total up time and down time for the current month, all of which is displayed in a calendar format. Preferably, the Availability by Application report is color coded to indicate whether the applicable service level agreement has been complied with for a particular day during which the application is monitored. The service level agreement information is entered via the service level agreement options folder, which is discussed above. For example, if application is available on a particular day less than 98% of the monitoring time period, the day is displayed in the color yellow. Similarly, if application is available on a particular day less than 96% of the monitoring time period, the day is displayed in the color red. If the application availability is within the parameters defined via the service level agreement options folder, then the day is not displayed in color. Preferably, days during which the application is not monitored are displayed in the color gray. Also, it is preferable that if the application availability is 100% during the previous month and cunent month, a message so indicating would be displayed, and the Availability by Application report would not be displayed. In other words, the Availability by Application report is displayed if the application availability for the relevant time period is less than 100%.

An application error log for a particular day can be displayed by selecting that day from the calendar displayed in the Availability by Application report. Figure 69 is an illustrative application error log.

Returning to Figure 62, to access the Retrieve Old Logs web page, Retrieve Old Application Logs link 627 is selected for the selected application. The Retrieve Old Logs web page allows access to error logs that are generated by the monitors and displayed on the application's results page. As can be seen from Figure 70, these logs are organized by application and date. To access a particular error log, the check box associated with that error log is selected, and the Submit Query button 701 is selected, which will cause the Old Logs web page to be displayed. An exemplary Old Logs web page is that illustrated in Figure 69. As can be seen from Figure 69, theOld Logs web displays the following log information: resource 691, description 692, time of error 693, and response expected 694.

Returning to Figure 62, to access a Customer Experience Report for a selected application, the Customer Experience Report link 628 is selected. An illustrative Customer Experience Report is shown in Figure 71. As can be seen in Figure 71 the Customer Experience Report provides following detailed information about the availability of the resource functions of a given monitor: the time period during which the resource function is being monitored; the availability of the resource; the average amount of time the resource function takes to respond; and the percentage of the time that the amount of time to test the resource function exceeds one (1) second.

The above description of the preferred embodiments detail many ways in which the present invention can provide its intended puφoses. Programmers skilled in the art are able to produce workable computer programs to practice the teachings set forth above. While several preferred embodiments are described in detail hereinabove, it is apparent that various changes might be made without departing from the scope of the invention, which is set forth in the accompanying claims.

Claims

What is claimed is:

1. A computer based system for monitoring the performance of a target system, wherein the target system is comprised of at least one resource to be tested, and the at least one resource performs at least one resource function to be tested, comprising: a monitoring application program for generating a resource function test request and receiving a resource function test response; and a target system interface for receiving the resource function test request from the monitoring application program, sending the resource function test request to the target system, receiving the resource function test response from the target system, and sending the resource function test response to the monitoring application program; wherein, the monitoring application communicates with the target system interface in a first communications protocol, the target system interface converts the resource function test request from the first communications protocol into a second communications protocol, and the target system interface communicates with the target system in the second communications protocol.

2. The system of 1 , wherein the first communications protocol is a hypertext transport protocol (http).

3. The system of claim 1 , wherein the first communications protocol is a secure sockets layer protocol (https).

4. The system of claim 1 , wherein the second communications protocol is a communications protocol understood by the at least one resource to be tested.

5. The system of claim 1 , wherein the second communications protocol is an internet protocol.

6. The system of claim 5, wherein the internet protocol is a telnet protocol.

7. The system of claim 5, wherein the internet protocol is a simple network management protocol.

8. The system of claim 5, wherein the internet protocol is a simple mail transfer protocol.

9. The system of claim 5, wherein the internet protocol is a file transport protocol.

10. The system of claim 5, wherein the internet protocol is an internet message control protocol.

11. The system of claim 5, wherein the internet protocol is a telnet protocol.

12. The system of claim 1 , wherein the second communications protocol is a NetBIOS protocol.

13. The system of claim 1 , wherein the second communications protocol is a systems network architecture protocol.

14. The system of claim 1, wherein the target system interface is further comprised of a web server and the resource function test request is a request for a web page.

15. The system of claim 14, wherein the web page is an active server page.

16. The system of claim 14, wherein the web page is a Java server page.

17. The system of claim 14, wherein the web page is a common gateway interface bin script.

18. The system of claim 1 , further comprising a database operatively coupled to the monitoring application program, wherein resource function test request information and resource function test response information is stored in the database in association with the at least one resource function to be tested.

19. The system of claim 18, wherein the resource function test request information is comprised of uniform resource locator information

20. The system of claim 19, wherein the resource function test request information is further comprised of post data.

21. The system of claim 18, wherein the resource function test response information is comprised of an expected resource function test response.

22. The system of claim 21 , wherein the resource function test response information is further comprised of an actual resource function test response.

23. The system of claim 22, wherein the monitoring application program determines whether the actual resource function test response for the at least one resource to be tested is the expected resource function test response for the at least one resource to be tested.

24. The system of claim 23, wherein the monitoring application program causes a notification to be sent if the actual resource function test response for the at least one resource to be tested is not the expected resource function test response for the at least one resource to be tested.

25. The system of claim 24, wherein the notification is sent pursuant to predefined notification information.

26. The system of claim 25, wherein the predefined notification information is comprised of email notification information.

27. The system of claim 25, wherein the predefined notification information is comprised of pager notification information.

28. The system of claim 25, wherein the predefined notification information is stored in the database.

29. The system of claim 18, further comprising a web page publisher, wherein the web page publisher causes the publication of a web page that displays a diagram of the target system.

30. The system of claim 29, wherein the target system diagram is comprised of: a representation of the least one resource to be tested, an indication of the status of the at least one resource to be tested, and wherein, the status of the at least one resource to be tested is determined by the resource function test response information.

31. The system of claim 30, wherein the resource function test response information is comprised of one or more resource function test responses from the at least one resource to be tested.

32. The system of claim 29, wherein the at least one resource to be tested is tested according to predefined testing interval information.

33. The system of claim 32, wherein the web page that displays the target system diagram is published upon completion of the testing of the at least one resource to be tested according to the predefined testing interval information.

34. The system of claim 32, wherein the predefined interval testing information is stored in the database.

35. The system of claim 1, wherein the at least one resource to be tested is a database.

36. The system of claim 35, wherein the database is an ODBC compliant database.

37. The system of claim 1 , wherein the at least one resource to be tested is a computer accessible via an Internet protocol.

38. The system of claim 5, wherein the internet protocol is a telnet protocol.

39. The system of claim 5, wherein the internet protocol is a simple network management protocol.

40. The system of claim 5, wherein the internet protocol is a simple mail transfer protocol.

41. The system of claim 5, wherein the internet protocol is a file transport protocol.

42. The system of claim 5, wherein the internet protocol is an internet message control protocol.

43. The system of claim 5, wherein the internet protocol is a telnet protocol.

44. The system of claim 37, wherein the computer accessible via the Internet is a web server.

45. The system of claim 1 , wherein the at least one resource to be tested is a computer that is accessible via the Telnet protocol.

46. The system of claim 1, wherein the at least one resource to be tested is a mainframe computer.

47. The system of claim 46, wherein the mainframe computer can be accessed via a terminal emulation program.

48. The system of claim 47, wherein the terminal emulation program is

TN3270.

49. The system of claim 47, wherein the terminal emulation program is TN5250.

50. The system of claim 1, wherein the at least one resource to be tested is a log.

51. The system of claim 50, wherein the log is an event log.

52. The system of claim 1 , wherein the at least one resource to be tested is a computer accessible via a NetBIOS protocol.

53. The system of claim 1 , wherein the at least one resource to be tested is a computer accessible via a systems network architecture protocol.

54. A user interface to a system for monitoring the performance of a target system, wherein the target system is comprised of at least one resource to be tested, and the at least one resource performs at least one resource function to be tested, wherein the user interface is comprised of: a display of a diagram of the target system, wherein the target system diagram is comprised of: a representation of the at least one resource to be tested, an indication of the status of the at least one resource to be tested, and wherein, the status of the at least one resource to be tested is determined by one or more responses to the at least one resource function test of the resource function to be tested.

55. The user interface of claim 54, wherein the indication of the status of the at least one resource to be tested is a color.

56. The user interface of claim 55, wherein the resource status indication color is a first color if the status of the resource is acceptable.

57. The user interface of claim 56, wherein the resource status indication color is a second color if the status of the resource is not acceptable.

58. The user interface of claim 57, wherein the user interface displays one or more target system diagrams, wherein the displayed target system diagrams represent the target systems having at least one resource whose status is unacceptable.

59. The user interface of claim 54, wherein the target system diagram is displayed via a web page.

60. The user interface of claim 59, wherein the web page is an active server page.

61. The user interface of claim 54, further comprising a display of a resource function test response time graph.

62. The user interface of claim 61 , wherein the resource function test response time graph is comprised of information about an amount of time between a request for a resource function test and a response to the resource function test.

63. The user interface of claim 62, wherein the information about the amount of time between the request for a resource function test and the responseto the resource function test is calculated over a predetermined time period.

64. The user interface of claim 61 , wherein the resource function response time graph is displayed via a web page.

65. The user interface of claim 64, wherein the web page is an active server page.

66. The user interface of claim 54, further comprising a display of a resource function response time listing.

67. The user interface of claim 66, wherein the resource function test response time listing is comprised of information about an amount of time between a request for a resource function test and a response to the resource function test.

68. The user interface of claim 67, wherein the information about the amount of time between the request for a resource function test and the response to the resource function test is calculated over a predetermined time period.

69. The user interface of claim 66, wherein the resource function response time listing is displayed via a web page.

70. The user interface of claim 69, wherein the web page is an active server page.

71. A system for creating a monitor for a target system, wherein the target system is comprised of at least one resource to be tested, and the at least one resource performs at least one resource function to be tested, wherein the system is comprised of: a monitoring application program for defining the target system monitor, wherein the target system monitor is comprised of : monitor information; and resource function test information for each resource of the target application to be tested; a database for storing the monitor information and the resource function test information.

72. The system of claim 71 , wherein the monitor information is further comprised of test interval information, wherein the test interval information is comprised of an amount of time between testing cycles if the target system was functioning in an expected manner during the immediately preceding testing cycle.

73. The system of claim 71 , wherein the monitor information is further comprised of retest interval information, wherein the retest interval information is comprised of an amount of time between testing cycles if the target system was not functioning in an expected manner during the immediately preceding testing cycle.

74. The system of claim 72, wherein the monitor information is further comprised of notification interval information, wherein the notification interval information is comprised of an amount of time between the end of a testing cycle during which the monitoring application program determined that the target system was not functioning in an expected manner and when a notification is to be sent indicating the target system was not functioning in an expected manner.

75. The system of claim 74, wherein the notification is an email.

76. The system of claim 74, wherein the notification is a page.

77. The system of claim 74, wherein the notification is an SNMP alert.

78. The system of claim 71 , wherein the monitor information is further comprised of resource availability information, wherein the resource availability information is comprised of the amount of time that the at least one resource should be functioning in an expected manner.

79. The system of claim 71 , wherein the monitor information is further comprised of resource unavailability information, wherein the resource unavailability information is comprised of the amount of time that the at least one resource may not be functioning in an expected manner.

80. The system of claim 71 , wherein the resource function test information is comprised of an expected resource function test response for each resource function to be tested for each resource to be tested.

81. The system of claim 71 , wherein the resource function test information is further comprised of an actual resource function test response.

82. The system of claim 71 , wherein the resource function test information is further comprised of uniform resource locator information.

83. The system of claim 71 , wherein the resource function test information is further comprised of post data.

84. A computer based system for creating a resource function test program to test at least one resource function of at least one resource of a target system, wherein the resource function test program sends a resource function test request to the at least one resource to be tested and receives from the at least one resource function to be tested a resource function test response, comprising: a recorder for receiving information from a user to be input into the at least one resource to be tested and for receiving output generated by the at least one resource to be tested in response to the user input; a database for storing the information received from the user to be input into the at least one resource to be tested and storing the output generated by the at least one resource to be tested; wherein the resource function test program is automatically generated based on the input into the at least one resource to be tested and the output generated by the at least one resource to be tested.

85. The system of claim 84, wherein the resource function test program is a web page.

86. The system of claim 85, wherein the web page is an active server page.

87. The system of claim 85, wherein the web page is a Java server page.

88. The system of claim 85, wherein the web page is a common gateway interface bin script.

89. The system of claim 84, wherein the resource function test program tests a plurality of resource functions.

90. The system of claim 84, wherein the at least one resource to be tested is a database.

91. The system of claim 90, wherein the database is an ODBC compliant database.

92. The system of claim 84, wherein the at least one resource to be tested is a computer accessible via the Internet.

93. The system of claim 92, wherein the computer accessible via the Internet is a web server.

94. The system of claim 84, wherein the at least one resource to be tested is a computer that is accessible via the Telnet protocol.

95. The system of claim 84, wherein the at least one resource to be tested is a mainframe computer.

96. The system of claim 95, wherein the mainframe computer can be accessed via a terminal emulation program.

97. The system of claim 96, wherein the terminal emulation program is TN3270.

98. The system of claim 96, wherein the terminal emulation program is TN5250.

99. The system of claim 84, wherein the at least one resource to be tested is a log.

100. The system of claim 99, wherein the log is an event log.

101. A computer implemented method for monitoring the performance of a target system, wherein the target system is comprised of at least one resource to be tested, and the at least one resource performs at least one resource function to be tested, comprising: generating a resource function test request via a monitoring application program and receiving a resource function test response; and receiving the resource function test request via a target system interlace, sending the resource function test request to the target system, receiving the resource function test response from the target system, and sending the resource function test response to the monitoring application program; wherein, the monitoring application communicates with the target system interface in a first communications protocol, the target system interface converts the resource function test request from the first communications protocol into a second communications protocol, and the target system interface communicates with the target system in the second communications protocol.

102. The method ofl 01, wherein the first communications protocol is a hypertext transport protocol (http).

103. The method of claim 101, wherein the first communications protocol is a secure sockets layer protocol (https).

104. The method of claim 101, wherein the second communications protocol is a communications protocol understood by the at least one resource to be tested.

105. The method of claim 101, wherein the second communications protocol is an internet protocol.

106. The method of claim 105, wherein the internet protocol is a telnet protocol.

107. The method of claim 105, wherein the internet protocol is a simple network management protocol.

108. The method of claim 105, wherein the internet protocol is a simple mail transfer protocol.

109. The method of claim 105, wherein the internet protocol is a file transport protocol.

110. The method of claim 105, wherein the internet protocol is an internet message control protocol.

111. The method of claim 105, wherein the internet protocol is a telnet protocol.

112. The method of claim 101, wherein the second communications protocol is a NetBIOS protocol.

113. The method of claim 101, wherein the second communications protocol is a systems network architecture protocol.

114. The method of claim 101, wherein the target system interface is further comprised of a web server and the resource function test request is a request for a web page.

115. The method of claim 114, wherein the web page is an active server page.

116. The method of claim 114, wherein the web page is a Java server page.

117. The method of claim 114, wherein the web page is a common gateway interface bin script.

118. The method of claim 101, further comprising a database operatively coupled to the monitoring application program, wherein resource function test request information and resource function test response information is stored in the database in association with the at least one resource function to be tested.

119. The method of claim 118, wherein the resource function test request information is comprised of uniform resource locator information

120. The method of claim 119, wherein the resource function test request information is further comprised of post data.

121. The method of claim 118, wherein the resource function test response information is comprised of an expected resource function test response.

122. The method of claim 121, wherein the resource function test response information is further comprised of an actual resource function test response.

123. The method of claim 122, wherein the monitoring application program determines whether the actual resource function test response for the at least one resource to be tested is the expected resource function test response for the at least one resource to be tested.

124. The method of claim 123, wherein the monitoring application program causes a notification to be sent if the actual resource function test response for the at least one resource to be tested is not the expected resource function test response for the at least one resource to be tested.

125. The method of claim 124, wherein the notification is sent pursuant to predefined notification information.

126. The method of claim 125, wherein the predefined notification information is comprised of email notification information.

127. The method of claim 125, wherein the predefined notification information is comprised of pager notification information.

128. The method of claim 125, wherein the predefined notification information is stored in the database.

129. The method of claim 118, further comprising a web page publisher, wherein the web page publisher causes the publication of a web page that displays a diagram of the target system.

130. The method of claim 129, wherein the target system diagram is comprised of: a representation of the least one resource to be tested, an indication of the status of the at least one resource to be tested, and wherein, the status of the at least one resource to be tested is determined by the resource function test response information.

131. The method of claim 130, wherein the resource function test response information is comprised of one or more resource function test responses from the at least one resource to be tested.

132. The method of claim 129, wherein the at least one resource to be tested is tested according to predefined testing interval information.

133. The method of claim 132, wherein the web page that displays the target system diagram is published upon completion of the testing of the at least one resource to be tested according to the predefined testing interval information.

134. The method of claim 132, wherein the predefined interval testing information is stored in the database.

135. The method of claim 101, wherein the at least one resource to be tested is a database.

136. The method of claim 135, wherein the database is an ODBC compliant database.

137. The method of claim 101, wherein the at least one resource to be tested is a computer accessible via an Internet protocol.

138. The method of claim 101, wherein the internet protocol is a telnet protocol.

139. The method of claim 105, wherein the internet protocol is a simple network management protocol.

140. The method of claim 105, wherein the internet protocol is a simple mail transfer protocol.

141. The method of claim 105, wherein the internet protocol is a file transport protocol.

142. The method of claim 105, wherein the internet protocol is an internet message control protocol.

143. The method of claim 105, wherein the internet protocol is a telnet protocol.

144. The method of claim 137, wherein the computer accessible via the

Internet is a web server.

145. The method of claim 101, wherein the at least one resource to be tested is a computer that is accessible via the Telnet protocol.

146. The method of claim 101, wherein the at least one resource to be tested is a mainframe computer.

147. The method of claim 146, wherein the mainframe computer can be accessed via a terminal emulation program.

148. The method of claim 147, wherein the terminal emulation program is TN3270.

149. The method of claim 147, wherein the terminal emulation program is TN5250.

150. The method of claim 101, wherein the at least one resource to be tested is a log.

151. The method of claim 150, wherein the log is an event log.

152. The method of claim 101, wherein the at least one resource to be tested is a computer accessible via a NetBIOS protocol.

153. The method of claim 101, wherein the at least one resource to be tested is a computer accessible via a systems network architecture protocol.

154. A computer based method for generating a user interface to a system for monitoring the performance of a target system, wherein the target system is comprised of at least one resource to be tested, and the at least one resource performs at least one resource function to be tested, wherein the user interface is comprised of: a display of a diagram of the target system, wherein the target system diagram is comprised of: a representation of the at least one resource to be tested, an indication of the status of the at least one resource to be tested, and wherein, the status of the at least one resource to be tested is determined by one or more responses to the at least one resource function test of the resource function to be tested.

155. The method of claim 154, wherein the indication of the status of the at least one resource to be tested is a color.

156. The method of claim 155, wherein the resource status indication color is a first color if the status of the resource is acceptable.

157. The method of claim 156, wherein the resource status indication color is a second color if the status of the resource is not acceptable.

158. The method of claim 157, wherein the user interface displays one or more target system diagrams, wherein the displayed target system diagrams represent the target systems having at least one resource whose status is unacceptable.

159. The method of claim 154, wherein the target system diagram is displayed via a web page.

160. The method of claim 159, wherein the web page is an active server page.

161. The method of claim 154, wherein the user interface is further comprised of a display of a resource function test response time graph.

162. The method of claim 161, wherein the resource function test response time graph is comprised of information about an amount of time between a request for a resource function test and a response to the resource function test.

163. The method of claim 162, wherein the information about the amount of time between the request for a resource function test and the response to the resource function test is calculated over a predetermined time period.

164. The method of claim 161, wherein the resource function response time graph is displayed via a web page.

165. The method of claim 164, wherein the web page is an active server page.

166. The method of claim 154, wherein the user interface is further comprised of a display of a resource function response time listing.

167. The method of claim 166, wherein the resource function test response time listing is comprised of information about an amount of time between a request for a resource function test and a response to the resource function test.

168. The method of claim 167, wherein the information about the amount of time between the request for a resource function test and the response to the resource function test is calculated over a predetermined time period.

169. The method of claim 166, wherein the resource function response time listing is displayed via a web page.

170. The method of claim 169, wherein the web page is an active server page.

171. A method for creating a monitor for a target system, wherein the target system is comprised of at least one resource to be tested, and the at least one resource performs at least one resource function to be tested, wherein the system is comprised of: defining the target system monitor via a monitoring application program, wherein the target system monitor is comprised of : monitor information; and resource function test information for each resource of the target application to he tested; storing the monitor information and the resource function test information in a database.

172. The method of claim 171, wherein the monitor information is further comprised of test interval information, wherein the test interval information is comprised of an amount of time between testing cycles if the target system was functioning in an expected manner during the immediately preceding testing cycle.

173. The method of claim 171, wherein the monitor information is further comprised of retest interval information, wherein the retest interval information is comprised of an amount of time between testing cycles if the target system was not functioning in an expected manner during the immediately preceding testing cycle.

174. The method of claim 172, wherein the monitor information is further comprised of notification interval information, wherein the notification interval information is comprised of an amount of time between the end of a testing cycle during which the monitoring application program determined that the target system was not functioning in an expected manner and when a notification is to be sent indicating the target system was not functioning in an expected manner.

175. The method of claim 174, wherein the notification is an email.

176. The method of claim 174, wherein the notification is a page.

177. The method of claim 174, wherein the notification is an SNMP alert.

178. The method of claim 171, wherein the monitor information is further comprised of resource availability information, wherein the resource availability information is comprised of the amount of time that the at least one resource should be functioning in an expected manner.

179. The method of claim 171, wherein the monitor information is further comprised of resource unavailability information, wherein the resource unavailability information is comprised of the amount of time that the at least one resource may not he functioning in an expected manner.

180. The method of claim 171, wherein the resource function test information is comprised of an expected resource function test response for each resource function to be tested for each resource to be tested.

181. The method of claim 171, wherein the resource function test information is further comprised of an actual resource function test response.

182. The method of claim 171, wherein the resource function test information is further comprised of uniform resource locator information.

183. The method of claim 171, wherein the resource function test information is further comprised of post data.

184. A method for creating a resource function test program to test at least one resource function of at least one resource of a target system, wherein the resource function test program sends a resource function test request to the at least one resource to be tested and receives from the at least one resource function to be tested a resource function test response, comprising: receiving information from a user to be input into the at least one resource to be tested; storing the information received from the user to be input into the at least one resource to be tested; receiving output generated by the at least one resource to be tested in response to the user input; storing the output generated by the at least one resource to be tested; and automatically generating the resource function test program based on the input into the at least one resource to be tested and the output generated by the at least one resource to be tested.

185. The method of claim 184, wherein the resource function test program is a web page.

186. The method of claim 185, wherein the web page is an active server page.

187. The method of claim 185, wherein the web page is a java server page.

188. The method of claim 185, wherein the web page is a common gateway interface bin script.

189. The method of claim 184, wherein the resource function test program tests a plurality of resource functions.

190. The method of claim 184, wherein the at least one resource to be tested is a database.

191. The method of claim 190, wherein the database is an ODBC compliant database.

192. The method of claim 184, wherein the at least one resource to be tested is a computer accessible via the Internet.

193. The method of claim 192, wherein the computer accessible via the Internet is a web server.

194. The method of claim 184, wherein the at least one resource to be tested is a computer that is accessible via the Telnet protocol.

195. The method of claim 184, wherein the at least one resource to be tested is a mainframe computer.

196. The method of claim 195, wherein the mainframe computer can be accessed via a terminal emulation program.

197. The method of claim 196, wherein the terminal emulation program is TN3270.

198. The method of claim 196, wherein the terminal emulation program is

TN5250.

199. The method of claim 184, wherein the at least one resource to be tested is a log.

200. The method of claim 199, wherein the log is an event log.

201. A computer readable media comprising software for monitoring the performance of a target system, wherein the target system is comprised of at least one resource to be tested, and the at least one resource performs at least one resource function to be tested, comprising: generating a resource function test request via a monitoring application program and receiving a resource function test response; and receiving the resource function test request via a target system interface, sending the resource function test request to the target system, receiving the resource function test response from the target system, and sending the resource function test response to the monitoring application program; wherein, the monitoring application communicates with the target system interface in a first communications protocol, the target system interface converts the resource function test request from the first communications protocol into a second communications protocol, and the target system interface communicates with the target system in the second communications protocol.

202. The computer readable media of 201 , wherein the first communications protocol is a hypertext transport protocol (http).

203. The computer readable media of claim 201, wherein the first communications protocol is a secure sockets layer protocol (https).

204. The computer readable media of claim 201 , wherein the second communications protocol is a communications protocol understood by the at least one resource to be tested.

205. The computer readable media of claim 201, wherein the second communications protocol is an internet protocol.

206. The computer readable media of claim 205, wherein the internet protocol is a telnet protocol.

207. The computer readable media of claim 205, wherein the internet protocol is a simple network management protocol.

208. The computer readable media of claim 205, wherein the internet protocol is a simple mail transfer protocol.

209. The computer readable media of claim 205, wherein the internet protocol is a file transport protocol.

210. The computer readable media of claim 205, wherein the internet protocol is an internet message control protocol.

211. The computer readable media of claim 205, wherein the internet protocol is a telnet protocol.

212. The computer readable media of claim 201 , wherein the second communications protocol is a NetBIOS protocol.

213. The computer readable media of claim 201 , wherein the second communications protocol is a systems network architecture protocol.

214. The computer readable media of claim 201 , wherein the target system interface is further comprised of a web server and the resource function test request is a request for a web page.

215. The computer readable media of claim 214, wherein the web page is an active server page.

216. The computer readable media of claim 214, wherein the web page is a java server page.

217. The computer readable media of claim 214, wherein the web page is a common gateway interface bin script.

218. The computer readable media of claim 201, further comprising a database operatively coupled to the monitoring application program, wherein resource function test request information and resource function test response information is stored in the database in association with the at least one resource function to be tested.

219. The computer readable media of claim 218, wherein the resource function test request information is comprised of uniform resource locator information

220. The computer readable media of claim 219, wherein the resource function test request information is further comprised of post data.

221. The computer readable media of claim 218, wherein the resource function test response information is comprised of an expected resource function test response.

222. The computer readable media of claim 221 , wherein the resource function test response information is further comprised of an actual resource function test response.

223. The computer readable media of claim 222, wherein the monitoring application program determines whether the actual resource function test response for the at least one resource to be tested is the expected resource function test response for the at least one resource to be tested.

224. The computer readable media of claim 223, wherein the monitoring application program causes a notification to be sent if the actual resource function test response for the at least one resource to be tested is not the expected resource function test response for the at least one resource to be tested.

225. The computer readable media of claim 224, wherein the notification is sent pursuant to predefined notification information.

226. The computer readable media of claim 225, wherein the predefined notification information is comprised of email notification information.

227. The computer readable media of claim 225, wherein the predefined notification information is comprised of pager notification information.

228. The computer readable media of claim 225, wherein the predefined notification information is stored in the database.

229. The computer readable media of claim 218, further comprising a web page publisher, wherein the web page publisher causes the publication of a web page that displays a diagram of the target system.

230. The computer readable media of claim 229, wherein the target system diagram is comprised of: a representation of the least one resource to be tested, an indication of the status of the at least one resource to be tested, and wherein, the status of the at least one resource to be tested is determined by the resource function test response information.

231. The computer readable media of claim 230, wherein the resource function test response information is comprised of one or more resource function test responses from the at least one resource to be tested.

232. The computer readable media of claim 229, wherein the at least one resource to be tested is tested according to predefined testing interval information.

233. The computer readable media of claim 232, wherein the web page that displays the target system diagram is published upon completion of the testing of the at least one resource to be tested according to the predefined testing interval information.

234. The computer readable media of claim 232, wherein the predefined interval testing information is stored in the database.

235. The computer readable media of claim 201 , wherein the at least one resource to be tested is a database.

236. The computer readable media of claim 235, wherein the database is an ODBC compliant database.

237. The computer readable media of claim 201 , wherein the at least one resource to he tested is a computer accessible via an Internet protocol.

238. The computer readable media of claim 201, wherein the internet protocol is a telnet protocol.

239. The computer readable media of claim 205, wherein the internet protocol is a simple network management protocol.

240. The computer readable media of claim 205, wherein the internet protocol is a simple mail transfer protocol.

241. The computer readable media of claim 205, wherein the internet protocol is a file transport protocol.

242. The computer readable media of claim 205, wherein the internet protocol is an internet message control protocol.

243. The computer readable media of claim 205, wherein the internet protocol is a telnet protocol.

244. The computer readable media of claim 237, wherein the computer accessible via the Internet is a web server.

245. The computer readable media of claim 201 , wherein the at least one resource to be tested is a computer that is accessible via the Telnet protocol.

246. The computer readable media of claim 201, wherein the at least one resource to be tested is a mainframe computer.

247. The computer readable media of claim 246, wherein the mainframe computer can be accessed via a terminal emulation program.

248. The computer readable media of claim 247, wherein the terminal emulation program is TN3270.

249. The computer readable media of claim 247, wherein the terminal emulation program is TN5250.

250. The computer readable media of claim 101, wherein the at least one resource to be tested is a log.

251. The computer readable media of claim 250, wherein the log is an event log.

252. The computer readable media of claim 101, wherein the at least one resource to be tested is a computer accessible via a NetBIOS protocol.

253. The computer readable media of claim 101, wherein the at least one resource to be tested is a computer accessible via a systems network architecture protocol.

254. A computer readable media comprising software for generating a user interface to a system for monitoring the performance of a target system, wherein the target system is comprised of at least one resource to be tested, and the at least one resource performs at least one resource function to be tested, wherein the user interface is comprised of: a display of a diagram of the target system, wherein the target system diagram is comprised of: a representation of the at least one resource to be tested, an indication of the status of the at least one resource to be tested, and wherein, the status of the at least one resource to be tested is determined by one or more responses to the at least one resource function test of the resource function to be tested.

255. The computer readable media of claim 254, wherein the indication of the status of the at least one resource to be tested is a color.

256. The computer readable media of claim 255, wherein the resource status indication color is a first color if the status of the resource is acceptable.

257. The computer readable media of claim 256, wherein the resource status indication color is a second color if the status of the resource is not acceptable.

258. The computer readable media of claim 257, wherein the user interface displays one or more target system diagrams, wherein the displayed target system diagrams represent the target systems having at least one resource whose status is unacceptable.

259. The computer readable media of claim 254, wherein the target system diagram is displayed via a web page.

260. The computer readable media of claim 259, wherein the web page is an active server page.

261. The computer readable media of claim 254, wherein the user interface is further comprised of a display of a resource function test response time graph.

262. The computer readable media of claim 261 , wherein the resource function test response time graph is comprised of information about an amount of time between a request for a resource function test and a response to the resource function test.

263. The computer readable media of claim 262, wherein the information about the amount of time between the request for a resource function test and the response to the resource function test is calculated over a predetermined time period.

264. The computer readable media of claim 261, wherein the resource function response time graph is displayed via a web page.

265. The computer readable media of claim 264, wherein the web page is an active server page.

266. The computer readable media of claim 254, wherein the user interface is further comprised of a display of a resource function response time listing.

267. The computer readable media of claim 266, wherein the resource function test response time listing is comprised of information about an amount of time between a request for a resource function test and a response to the resource function test.

268. The computer readable media of claim 267, wherein the information about the amount of time between the request for a resource function test and the response to the resource function test is calculated over a predetermined time period.

269. The computer readable media of claim 266, wherein the resource function response time listing is displayed via a web page.

270. The computer readable media of claim 269, wherein the web page is an active server page.

271. A computer readable media for creating a monitor for a target system, wherein the target system is comprised of at least one resource to be tested, and the at least one resource performs at least one resource function to be tested, wherein the system is comprised of: defining the target system monitor via a monitoring application program, wherein the target system monitor is comprised of : monitor information; and resource function test information for each resource of the target application to be tested; storing the monitor information and the resource function test information in a database.

272. The computer readable media of claim 271 , wherein the monitor information is further comprised of test interval information, wherein the test interval information is comprised of an amount of time between testing cycles if the target system was functioning in an expected manner during the immediately preceding testing cycle.

273. The computer readable media of claim 271 , wherein the monitor information is further comprised of retest interval information, wherein the retest interval information is comprised of an amount of time between testing cycles if the target system was not functioning in an expected manner during the immediately preceding testing cycle.

274. The computer readable media of claim 272, wherein the monitor information is further comprised of notification interval information, wherein the notification interval information is comprised of an amount of time between the end of a testing cycle during which the monitoring application program determined that the target system was not functioning in an expected manner and when a notification is to be sent indicating the target system was not functioning in an expected manner.

275. The computer readable media of claim 274, wherein the notification is an email.

276. The computer readable media of claim 274, wherein the notification is a page.

277. The computer readable media of claim 274, wherein the notification is an SNMP alert.

278. The computer readable media of claim 271 , wherein the monitor information is further comprised of resource availability information, wherein the resource availability information is comprised of the amount of time that the at least one resource should be functioning in an expected manner.

279. The computer readable media of claim 271 , wherein the monitor information is further comprised of resource unavailability information, wherein the resource unavailability information is comprised of the amount of time that the at least one resource may not be functioning in an expected manner.

280. The computer readable media of claim 271 , wherein the resource function test information is comprised of an expected resource function test response for each resource function to be tested for each resource to he tested.

281. The computer readable media of claim 271 , wherein the resource function test information is further comprised of an actual resource function test response.

282. The computer readable media of claim 271, wherein the resource function test information is further comprised of uniform resource locator information.

283. The computer readable media of claim 271, wherein the resource function test information is further comprised of post data.

284. A computer readable media for creating a resource function test program to test at least one resource function of at least one resource of a target system, wherein the resource function test program sends a resource function test request to the at least one resource to be tested and receives from the at least one resource function to be tested a resource function test response, comprising: receiving information from a user to be input into the at least one resource to be tested; storing the information received from the user to be input into the at least one resource to be tested; receiving output generated by the at least one resource to be tested in response to the user input; storing the output generated by the at least one resource to be tested; and automatically generating the resource function test program based on the input into the at least one resource to be tested and the output generated by the at least one resource to be tested.

285. The computer readable media of claim 284, wherein the resource function test program is a web page.

286. The computer readable media of claim 285, wherein the web page is an active server page.

287. The computer readable media of claim 285, wherein the web page is a java server page.

288. The computer readable media of claim 285, wherein the web page is a common gateway interface bin script.

289. The computer readable media of claim 284, wherein the resource function test program tests a plurality of resource functions.

290. The computer readable media of claim 284, wherein the at least one resource to be tested is a database.

291. The computer readable media of claim 290, wherein the database is an ODBC compliant database.

292. The computer readable media of claim 284, wherein the at least one resource to be tested is a computer accessible via the Internet.

293. The computer readable media of claim 292, wherein the computer accessible via the Internet is a web server.

294. The computer readable media of claim 284, wherein the at least one resource to be tested is a computer that is accessible via the Telnet protocol.

295. The computer readable media of claim 284, wherein the at least one resource to be tested is a mainframe computer.

296. The computer readable media of claim 295, wherein the mainframe computer can be accessed via a terminal emulation program.

297. The computer readable media of claim 296, wherein the terminal emulation program is TN3270.

298. The computer readable media of claim 296, wherein the terminal emulation program is TN5250.

299. The computer readable media of claim 284, wherein the at least one resource to be tested is a log.

300. The computer readable media of claim 299, wherein the log is an event log.