Dynamic connection to a remote tool in a distributed processing system environment used for debugging

Abstract

The present invention provides a dynamic connection for distributed applications that need to locate application development tools, including but not limited to debuggers, trace collection tools, compilers, etc.) which may be running on different machines, and to send the tools messages. The program requesting debugging service (i.e., a debugger client) sends, to a tool locator, criteria which specifies the properties of a desired debugger. The tool locator maintains a registry of all tools, e.g. debuggers, and their properties, which remain active within the network by receiving tool registration information from each tool as it is started on any machine within the network. When a message is received by the tool locator from a debugger client specifying the criteria of a desired debugger, the tool locator searches its registry and returns a list of debuggers matching the specified properties along with a communication endpoint address that can be used to establish a connection with a debugger meeting the criteria. The debugger client then sends a message, using the established connection, to the desired debugger requesting debugging services on behalf of the debugger client or another program. As a result, a dynamic connection is made, at run time, between an application program and a debugger having certain desired properties wherein the debugger may be active, if at all, at any time on any machine within the network.

Claims

We claim:

1. A method for debugging an application program in a network of processing systems, the method comprising:

calling a library routine, by the application program, to verify whether a debugger back-end is attached to a process running the application program, and if not, performing the following steps:

(i) invoking a routine, by the application program, to obtain a communication endpoint address of a debugger through a tool locator;

(ii) establishing a connection to the debugger using the communication endpoint address; and

(iii) sending the debugger, using the established connection, a debugging request to attach a back-end of the debugger to the process running the application program.

2. A method, in a network of processing systems, for debugging an application program, the method comprising:

enabling an application program, running on a first machine within the network of processing systems, to locate, at run time, a distributed debugger front-end running on a different machine;

sending, from the application to the located debugger front-end, a message requesting debugging services; and

attaching a back-end of the distributed debugger to a process for which debugging services is requested

wherein the message specifies information to obtain authorization for the debugger to attach a back-end of the debugger to the debuggee.

3. A system, in a network of processing systems, for debugging an application program, the system comprising:

means for enabling an application program, running on a first machine within the network of processing systems, to locate, at run time, a distributed debugger front-end running on a different machine;

means for sending, from the application to the located debugger front-end, a message requesting debugging services; and

means for attaching a back-end of the distributed debugger to a process for which debugging services is requested

wherein the message specifies information to obtain authorization for the debugger to attach a back-end of the debugger to the debuggee.

4. A method for debugging at least one DBMS external program in a network of processing systems, the method comprising:

initiating an execution, by a client program running on a first machine in the network, of the at least one DBMS external program;

loading, by a DBMS running on a second machine, each of the at least one external program in a separate process;

prior to executing the at least one external program, calling a library routine, by the DBMS, to verify whether a debugger back-end is attached to the separate process, and if not, performing the following steps:

(i) invoking a routine, by the DBMS, to obtain a communication endpoint address of a debugger through a tool locator;

(ii) establishing a connection to the debugger using the communication endpoint address;

(iii) sending the debugger, using the established connection, a debugging request to attach a back-end of the debugger to at least one of each of the separate process running each of the at least one DBMS external program; and

running the at least one separate process, under the control of the debugger, to an executable statement of the DBMS external program, and executing a breakpoint to allow the DBMS external program to be debugged by using debugging commands of the debugger.

5. A method for debugging at least one transaction program in a network of processing systems, the method comprising:

invoking the at least one transaction program, by a client program running on a first machine in the network;

allocating, by a transaction monitor running on a second machine, a separate process to load each of the at least one transaction program;

prior to executing the transaction program, calling a library routine, by the transaction monitor, to verify whether a debugger back-end is attached to the separate process, and if not, performing the following steps:

(i) invoking a routine, by the transaction monitor, to obtain a communication endpoint address of a debugger through a tool locator;

(ii) establishing a connection to the debugger using the communication endpoint address;

(iii) sending the debugger, using the established connection, a debugging request to attach a back-end of the debugger to the separate process running the transaction program; and

running the at least one separate process, under the control of the debugger, to an executable statement of the transaction program, and executing a breakpoint to allow the transaction program to be debugged by using debugging commands of the debugger.

6. A method for debugging a message queuing program in a network of processing systems, the method comprising:

queuing a message, by a client program running on a first machine in the network, to a queue on a second machine;

allocating, by a message queuing system running on a second machine, a separate process to load a message server program;

prior to executing the message server program, calling a library routine, by the message queuing system, to verify whether a debugger back-end is attached to the separate process, and if not, performing the following steps:

(i) invoking a routine, by the message queuing system, to obtain a communication endpoint address of a debugger through a tool locator;

(ii) establishing a connection to the debugger using the communication endpoint address;

(iii) sending the debugger, using the established connection, a debugging request to attach a back-end of the debugger to the separate process running the message server program; and

running the separate process, under the control of the debugger, to an executable statement of the message server program, and executing a breakpoint to allow the message server program to be debugged by using debugging commands of the debugger.

7. A method for debugging an object method of a distributed object in a network of processing systems, the method comprising:

invoking the object method of the distributed object, by a client program running on a first machine in the network;

allocating, by a distributed object system running on a second machine, a separate process to load a program that contains the object method of the distributed object;

prior to executing the object method of the distributed object, calling a library routine, by the distributed object system, to verify whether a debugger back-end is attached to the separate process, and if not, performing the following steps:

(i) invoking a routine, by the distributed object system, to obtain a communication endpoint address of a debugger through a tool locator;

(ii) establishing a connection to the debugger using the communication endpoint address;

(iii) sending the debugger, using the established connection, a debugging request to attach a back-end of the debugger to the separate process running the object method of the distributed object; and

running the object method of the distributed object, under the control of the debugger, to an executable statement of the object method of the distributed object, and executing a breakpoint to allow the object method of the distributed object to be debugged by using debugging commands of the debugger.

8. A method for locating application development tools (tools) within a network of processing systems, the method comprising:

receiving, from a tool, a registration of the tool, when the tool is started on any machine within the network, indicating certain properties of the tool;

maintaining a list of tools and corresponding properties for which the registration of the tools has been received;

receiving, from an application program, a boolean expression of search criteria specifying desired properties for a desired tool;

returning, to the application program, at least one located tool meeting the search criteria and a communication endpoint address that can be used to establish a dynamic connection with the located tool; and

maintaining a cursor position, in the list of tools, at the tool meeting the search criteria returned; and finding a next tool, upon receipt of a request to find the next tool, meeting the search criteria if more than one tool meets the search criteria.

9. The method of claim 8 further comprising means for maintaining an association between the cursor position and the application program from which the search criteria is received whereby search criteria from more than one application program can be received in a current session.

10. A method for invoking a debugger in a network of processing systems, the method comprising:

sending, to a tool locator, from a debugger client running on a first machine in the network, a boolean expression of search a criteria specifying desired properties of a desired debugger;

receiving, from the tool locator, a located debugger meeting the search criteria of the desired debugger and a communication endpoint address that can be used to establish a connection with the located debugger;

sending to the located debugger, from the debugger client, a message requesting debugging services for a debugee

wherein the message specifies information to obtain authorization for the debugger to attach a back-end of the debugger to the debugee.

11. The method of claim 10 wherein the step of receiving the located debugger meeting search the criteria of the desired debugger comprises receiving a list of debuggers meeting the search criteria.

12. The method of claim 10 wherein the debugger client is a software system and the debugee is a user's program.

13. The method of claim 10 wherein the debugger client is an application program different from the debugee.

14. The method of claim 10 wherein the debugger client and the debugee is a same user's program.

15. The method of claim 10 wherein the message requesting debugging services specifies information for the debugger to locate the debugee.

16. The method of claim 10 wherein the information includes network ID of the debugee machine, address-space ID, and a thread ID.

17. The method of claim 10 wherein the information includes login ID and password.

18. The method of claim 10 wherein the message specifies an entry point in the debugee where the debugging session should begin.

19. A computer program product comprising:

a computer usable medium having computer programming code embodied therein comprising:

a first set of routines to be called by a tool located within a network of processing systems comprising:

a first routine for adding an address of the tool to a registry;

a second routine for deleting the address from the registry;

a third routine for indicating that the tool is still available to provide services; and

a second set of routines to be called by a client requesting tool services comprising:

a fourth routine for beginning a search of the registry to locate a desired tool;

a fifth routine for retrieving the address of a next tool that matches a given specification; and

a sixth routine for ending a search of the registry.

20. A computer program product comprising:

a computer usable medium having computer programming code embodied therein comprising:

means for receiving a first set of messages from a tool located within a network of processing systems comprising:

a first message for adding an address of the tool to a registry;

a second message for deleting the address from the registry;

a third message for indicating that the tool is still available to provide services; and

means for receiving a second set of messages to be called by a client requesting tool services comprising:

a fourth message for beginning a search of the registry to locate a desired tool;

a fifth message for retrieving the address of a next tool that matches a given specification;

a sixth message for ending a search of the registry; and

a seventh message for requesting services of the tool.

21. A computer program product comprising:

a computer usable medium having computer programming code embodied therein comprising:

means for receiving, from an application development tool, a registration of the tool, when the tool is started on any machine within a network of machines, indicating certain properties of the tool;

means for maintaining a list of tools and corresponding properties for which the registration of the tools has been received;

means for receiving, from an application program, a boolean expression of search criteria specifying desired properties for a desired tool to be used in conjunction with the application program;

means for returning, to the application program, at least one located tool meeting the search criteria and a communication endpoint address that can be used to establish a connection with the located tool; and

means for maintaining a cursor position, in the list of tools, at the tool meeting the search criteria returned; and means for finding a next tool, upon receipt of a request to find the next tool, meeting the search criteria if more than one tool meets the search criteria.

22. The computer program product of claim 21 wherein the means for maintaining a list of tools further comprises means for creating a structure having a first pointer to a next registry item; a second pointer to a previous registry item; the properties of the tool, the address of the tool; a frequency in seconds that the tool will send still available messages; and a time indicating either an entry for the tool was initialized or a last time the still available message was received.

23. The computer program product of claim 21, wherein the computer usable medium having computer programming code embodied therein further comprises means for maintaining an association between the cursor position and the application program from which the search criteria is received whereby search criteria from more than one application program can be received in a current session.

24. A tool locator mechanism for locating application development tools running within a network of processing systems, the tool locator mechanism comprising:

means for receiving, from a tool, a registration of the tool, when the tool is started on any machine within the network, indicating certain properties of the tool;

means for maintaining a list of tools and corresponding properties for which the registration of the tools has been received;

means for receiving, from an application program, a boolean expression of search criteria specifying desired properties for a desired tool;

means for returning, to the application program, at least one located tool meeting the search criteria and a communication endpoint address that can be used to establish a connection with the located tool; and

means for maintaining a cursor position, in the list of tools, at the tool meeting the search criteria returned; and means for finding a next tool, upon receipt of a request to find the next tool, meeting the search criteria if more than one tool meets the search criteria.

25. The tool locator mechanism of claim 24 further comprising means for maintaining an association between the cursor position and the application program from which the search criteria is received whereby search criteria from more than one application program can be received in a current session.

26. A system for debugging a debugee residing on a first machine in a network of processing systems wherein a debugger may reside on a second machine in the network of processing systems, the system comprising:

means for sending, by a debugger client, to a tool locator, a boolean expression of search criteria specifying desired properties of a desired debugger;

means for receiving, from the tool locator, a communication endpoint address that can be used to establish a connection to the debugger meeting the search criteria of the desired debugger;

means for sending, by the debugger client, using the received communication endpoint address, a debugging request message for the debugger to debug the debugee;

means for having the debugee debugged by the debugger; and

wherein the message specifies information to obtain authorization for the debugger to attach a back-end of the debugger to the debuggee.

27. The system of claim 26 wherein the debugger client is the debugee.

28. The system of claim 26 wherein the debugger client is an application program different from the debugee.

29. The system of claim 26 wherein the debugger client is a software system and the debugee is a user's program.

30. The system of claim 26 wherein the debugging request message contains an address of the first machine where the debugee is running; an user id, a password of the user id, an address space id, and a thread id that the debugee is running under; and an instruction address where a debugging session should begin.

Description

BACKGROUND OF THE INVENTION

1. Field of the Invention

This invention relates to systems, methods, and programs for utilizing application development tools in a client/server and/or distributed processing system environment, and more generally, in a network of processing systems, and more specifically, for utilizing a debugger to debug parts of application programs that may run on different machines in such an environment.

2. Description of the Related Art

A distributed processing environment includes two or more processing nodes connected by a communications link, i.e., a network. At each processing node, there may be at least one processor, and any assortment of memory devices, storage devices, and input/output devices such as keyboards, displays, etc. The advantages of a distributed processing system include being able to utilize the resources (e.g., files, applications, tools, storage, etc.) resident at another node in the network. However, technical difficulties arise in trying to utilize and take advantage of these resources in a distributed environment. More specifically, technical difficulties arise when parts of an application program execute on different machines, especially when one desires to debug such an application program. Difficulties also arise when a debugger may reside on a different machine than the program to be debugged or may reside anywhere within a network of machines.

When developing a user's program that may be running in a distributed environment and is embedded within a larger application not written by the user, it is often difficult to debug the user's program. For example, for a CICS.TM. transaction, a DB/2.TM. stored procedure, trigger, user-defined functions, and code utilizing object-oriented frameworks, the developer of the larger program, in many cases, will only provide an application program interface (API) and a specification of its behavior. Source code for the larger program or information on its implementation is often not provided to allow its developer greater flexibility in making changes such as enhancements and bug fixes. In addition, for distributed client/server applications such as a CICS.TM. transaction, DB2.TM. stored procedure, or DSOM server, the application programs are executed under the control of a software system such as the CICS.TM. transactions manager, DB2.TM. database management system, or DSOM runtime environment. As such, the software system and various parts of an application program may be executing on different machines. This makes it difficult to run the application program under a debugger because it is not easy to determine when the application program will be invoked by the software system and, in some cases, what process and/or machine it will run in. In addition, it is difficult, if not impossible, for a debugger to penetrate all the layers of code in the large software systems in order to find the smaller programs (e.g., stored procedures, user-defined functions, CICS.TM. transaction) to debug.

CICS.TM. (Customer Information Control System) is a transaction monitoring system which provides a high level of efficiency for executing, including executing concurrently, thousands of multiple short running application programs, i.e., transaction programs. For example, many financial transactions, e.g., debiting accounts, crediting accounts, transfers, etc., may run under a transaction monitor. Transaction monitors that run on workstation platforms such as the UNIX.TM. operating system and OS/2.TM. operating system have similarities in their architecture. Such transaction monitors include CICS.TM./6000, TUXEDO,.TM. and ENCINA.TM., to name a few.

The technology of running external programs on the server side of a Relational Database Management System (RDBMS) has been developed in the past few years. For example, DB2.TM./Common-Server for AIX.TM./6000 (DB2.TM./CS) supports external programs. External programs are written by the application developer in a host 3GL language such as C and C++. They could be invoked by the RDBMS in one of two forms: (1) as a subprogram running inside of the server's "address space" (also referred to as "process"), or (2) as a stand-alone application running on the server machine. The former is usually referred to as User-Defined Functions (UDF), and the latter is referred to as Stored Procedures.

A stored procedure allows the application developer to break a database application program into a client part and a server part. A stored procedure is a precompiled program that is stored at the server site and invoked from the client. The server part can issue SQL language request while running on the same machine as the RDBMS server such as a DB2.TM./CS server. Results from the execution of the stored procedure can be passed back to the client part which is usually running on a different machine. In many applications, this can greatly improve the performance of the database application. Stored procedures reduce the network traffic between the client and the server. Other advantages include concealing a variety of system-specific and/or database-specific details from the user, thereby providing a greater degree of data independence; sharing a stored procedure by many clients; and providing enhanced security by authorizing a given user to invoke a given procedure but not to operate directly on the data accessed by that procedure.

In addition, the following described invention is also applicable to triggers. A trigger allows a user to associate certain SQL operations with a certain event. A trigger is a procedure that is to be invoked, by the database management system, when a specific condition occurs. For example, a trigger could be invoked to check the range value of employees' salaries whenever an SQL update is made to an employee/salary table to ensure that no salary goes above a certain amount. More specifically, an external trigger is a trigger than runs externally from the system software, i.e., a DBMS.

UDF (User-Defined Function) is, as its name implies, a function that takes in input and returns single value results. As a function, it must be embedded in an SQL expression. UDF is an innovative feature introduced in release 2 of the IBM DB2.TM./6000 relational database system. In addition, the new SQL3 standard provides a definition for user-defined functions. A user-defined function extends the functionality of the underlying DBMS (Data Base Management System) such as DB2.TM./CS by allowing users to define their own SQL functions implemented in a 3GL host language such as C and C++. Once created in the DBMS, UDFs can be invoked from any context where a SQL expression is expected or invoked from within any SQL expression as if they were built-in functions.

In a practical implementation, UDF could be run under two kinds of environment. For better security, a "firewall" is created between the database engine run-time and the UDF run-time. This is normally achieved by running UDF code in a separate process which is different from the engine process. Such a UDF is called a fenced UDF. In contrast, for better performance, UDF code is run in the same process as that of the database engine. Such a UDF is called an un-fenced UDF.

There are two components associated with a UDF: the specification component and the realization component. The former is specified by the create function SQL statement and maintained by the DBMS. The latter is specified by code written in a host language, prepared using the host language compiler and linkage editor, and maintained by the operating system. Different UDFs can share the same implementation. In other words, one realization component can be associated with more than one specification component. One situation where this can occur is when two UDFs have the same functionality but different runtime environments: one runs in a fenced mode, and the other runs in an unfenced mode.

Currently, there is no practical method for debugging external programs. The current practice is to write a test driver program which simulates the DB2.TM./CS call to the external program.

The main problem with debugging external programs is that the external programs are executed under the control of the database engine which is itself a large software system for which no source code is provided. It is therefore impractical for a debugger to penetrate through the layers of software of the database engine to locate and debug the external programs. It is also very difficult for the debugger to determine when an external program will be invoked by the database engine and which process it will be run in. External programs are not statically linked with any executable module. Instead, they are dynamically loaded by the database engine at run-time when the associated UDF or stored procedure is about to be invoked which further complicates the situation for the debugger. In addition, in an environment where the DBMS is shared between a large number of users, it is necessary to ensure that the debugger does not violate the security of the DBMS or the underlying operating system.

Debugging multi-threaded applications in a distributed environment is known. One approach is to attach a debugger to the main software system and attempt to penetrate all of the software layers to get to the desired part of the program to be debugged. Another approach will stop execution in all of the threads and processes in order to debug an application running in one of the threads. Stopping the execution of processes in a single user environment may be acceptable, but such an approach is unacceptable in multi-user environments or where hundreds of processes may be running as in a CICS.TM. transaction monitoring system.

The Parallel and Distributed Dynamic Analyzer (PDDA) is a parallel and distributed debugger that can debug parallel and distributed applications including distributed middleware (e.g., CICS.TM./6000, DCE and DSOM) and DB2.TM./6000 application programs that use RPC and threads.

It is also known to have "application program initiating" debugging wherein an application program, itself, requests the services of a serial debugger when the debugger and application are running on the same machine.

However, it is not known to have an application program, itself, initiate debugging in a distributed environment where the debugger may be running on a different machine, or on several machines, different from the machine the application program is running on. Furthermore, it is not known to have "program-initiating" debugging for RDBMs external programs or transaction programs in a distributed environment. In a distributed environment, a problem arises in not being able to locate the machine or process within the machine that a desired debugger is running on. This difficulty is similar for locating any application development tool desired by an application running in a distributed processing environment.

SUMMARY OF THE INVENTION

It is an object of this invention to provide a mechanism for locating tools in a distributed environment and to have the capability to send the tools messages.

It is a further object of this invention to have an application program initiated debugging mechanism in which an application program requests debugging services from a remote debugger in a distributed environment.

It is a further object of this invention to have an application program initiated debugging mechanism in which a software system requests debugging services from a remote debugger on behalf of an application program in a distributed environment.

It is a further object of this invention to dynamically connect, at run time, an application program requesting debugging services from a debugger meeting a specified criteria of properties wherein the debugger may be active, if at all, on any machine within a network of processing systems.

This invention allows an user program to locate tools in a distributed environment and to send the tools messages. It provides a mechanism that allows users to add a statement to their program to invoke a tool library routine to request services from a tool that may be running on a different machine in the distributed environment. Additionally, a program may request services from a tool on behalf of another program. The preferred embodiment discloses the invention with respect to a tool such as a debugger. However, the invention is applicable to other tools including, but not limited to, trace collection tools and compilers. Although the preferred embodiment discloses the invention in context of external programs running in a relational database management system (RDBMS) and transaction programs running in a transaction monitoring system, the invention is applicable to other database management systems (DBMS) including, but not limited, to object-oriented database systems, to distributed objects, to other transaction monitoring systems, to message queuing systems, and to other software systems, in general.

The invention is an "application program initiated" debugging mechanism. A typical implementation may include both a debugger initiated mechanism and the application program initiated debugging mechanism of this invention. For example, a debugger may initiate debugging with a client program. However, when the client program invokes a software system (e.g., a database management system, transaction monitoring system, or a message queuing system) and application programs are then executed under the control of the software system, the application programs can initiate a debugging session, or the software system can initiate the debugging session on behalf of the application programs.

More specifically, a first aspect of this invention allows a user program to initiate a request for debugging services and to locate a debugger that may be running on a different machine. This invention allows users to add a statement to their program in order to invoke a debugger library routine ("debugMe") to request debugging services from a debugger. After receiving the request, the debugger will dynamically attach a monitor/controller to the user's program and begin a debugging session. For example, after a CICS.TM. transaction begins executing in a CICS.TM. application server process, the user's transaction program calls a debugger library routine named DEBUGME to locate and send a message to a particular debugger requesting debugging services. The debugger will attach a monitor/controller to the application process that executed the debugMe routine and add an entry for that process to a list of processes that it's debugging.

A second aspect of this invention allows a program to request debugging services on behalf of another program by invoking a library routine ("debugIt"). For instance, the software system can request debugging services on behalf of an application program. In this case, the user's application program does not need to be modified. For example, after a CICS.TM. transaction is dynamically loaded into the CICS.TM. application server process, CICS.TM. can call a debugger library routine named DEBUGIT to send a message to a particular debugger. The call to the debugIt routine specifies all of the information necessary for the debugger to locate the user's program including the internet ID of the machine, address-space ID (e.g., UNIX.TM. process ID), and thread ID. Also included is the information necessary to obtain authorization for the debugger to attach a monitor/controller to the user's program (i.e., login ID and password) as well as the instruction address in the user's program where the debugging session should begin (e.g., the entry point of the user's program). The debugger would then attach a monitor/controller to the application process and add that process to the list of processes it is debugging.

To locate a debugger, a tool locator mechanism is used. To locate a debugger, the tool locator can identify a machine and a port (typically, also the process) within a machine in which a debugger is running. The tool locator returns a communication endpoint address of a desired debugger so that a connection can be established with the debugger. The program sends a search criteria to the tool locator to identify which debugger it wants, such as a debugger that is running on a certain machine. The tool locator, will then return a session list which is a list of all debuggers that meet the search criteria requested.

In a preferred embodiment, the invention is used in conjunction with a parallel and distributed debugger having a front-end that is running on different machine than the machine running the program to be debugged. A program initiates a first routine that identifies a program to be debugged, and then initiates a second routine to locate, via the tool locator, a front-end of a debugger to have a back-end of the debugger from another machine attach to the program to be debugged.

In this way, a dynamic connection can be made, at run time, within a network of processing systems, between an application program and a remote tool. The application program can initiate the request for services of a desired tool without knowing, initially, the location of the tool within the network. The tool locator provides the information necessary, independently of the application program, to make the dynamic connection at run time between the application program and a remote tool.

BRIEF DESCRIPTION OF THE DRAWING

For a more complete understanding of this invention, reference is now made to the following detailed description of the embodiments as illustrated in the accompanying drawing, wherein:

FIG. 1 is pictorial block diagram representation of a debugger component architecture of the Parallel and Distributed Dynamic Analyzer (PDDA) debugger for multiple client/server programs in accordance with the present invention;

FIG. 2 illustrates a dynamic connection to a debugger in a distributed environment, and more specifically, the steps for the case where a client requests debugging services for another program;

FIG. 3 illustrates the tool locator control flow;

FIG. 4 illustrates the control flow of the client debugIt Routine;

FIG. 5 illustrates a debugging environment of a DB2.TM./6000 application;

FIG. 6 illustrates a debugging environment of a CICS.TM./6000 application;

FIG. 7 is a pictorial representation of a distributed data processing system which may be used to implement the method of the present invention;

FIG. 8 is pictorial block diagram representation of a debugger component architecture in accordance with the present invention; and

FIG. 9 is pictorial block diagram representation of controller and address-space data structures of a debugger front-end in accordance with the present invention.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

For purposes of the following description, the following definitions will be used. A software system is a database management system, or a transaction monitoring system, or a message queuing system (e.g., work flow systems), or similar system which provides processing services to client programs. A software system can also be defined as middleware which is defined as software functions that reside between the operating system and applications. A client program or client application will refer to an application program that invokes the software system to request the services of the software system. The client program may either be a previously created program or one entered interactively by a user using an interactive SQL interface. The client program will typically run on a client machine separate from the machine running the software system, but they could be on the same machine. An external program is a program written in a host language other than the SQL language, itself. External programs include stored procedures, triggers, user-defined functions or other user code that is invoked by, and under the control of, the software system, e.g., the database management system, but is external to, and not a part of, the software system, and is a separate executable from the client program. A transaction program is invoked by, and under the control of, a transaction monitoring system but is external to, and not a part of the software system, and is a separate executable from the client program. An application program or user program is an external program or a transaction program or client program or other user code.

A preferred embodiment of the invention integrates the invention into a Parallel and Distributed Dynamic Analyzer (PDDA) debugger to debug distributed middleware (e.g., CICS.TM./6000, DCE, and DSOM) and DB2.TM./6000 application programs. Although the preferred embodiment of the invention is based on the PDDA debugger, any distributed and/or parallel debugger could be implemented together with this invention. Also, a serial debugger could be implemented with this invention as it is known to adapt serial debuggers to a distributed environment. In addition, although the following invention is described with reference to a debugger, the invention can be implemented with any application development tool such as trace collection tools, compilers, etc.

To understand the context of this invention, a brief description of the architecture of PDDA follows. A more detailed description of the PDDA debugger is given further below.

Overview of the PDDA Debugger

PDDA is a debugger for parallel and distributed applications using Open Software Foundation's Distributed Computing Environment (DCE). The PDDA debugger has also been extended to support the debugging Distributed System Object Model (D-SOM) application. As shown in FIG. 1, the PDDA debugger includes a front-end 100 and one or more back-ends 101, 102, 103 which are attached to the processes that are running the application programs using the underlying debugging support of the operating system (e.g., the AIX.TM./6000 "ptrace" function). The back-ends provide functions of monitors/controllers as illustrated in FIG. 1. The front-end 100 provides a single user interface and handles most of the initialization and parallel execution control issues. The front-end 100 creates a back-end 101, 102, 103 for each program 111, 112, 113 involved in the application. The back-end 101 runs on the same machine as the application program 111. The back-end 101 carries out requests from the front-end 100 to monitor and control the application program 111. This includes: reading and writing the program state, starting and stopping the execution of the program, and monitoring the program for interrupts (e.g., breakpoint, floating point exception, etc.).

Overview of the Invention

A back-end 101 (FIG. 1) can either be created during debugger initialization or it can be created dynamically during the debugging session by using this invention. When the back-end is created during initialization, the program to be monitored and controlled must be specified at initialization. When the back-end is created dynamically, the program to be monitored and controlled is NOT specified at debugger initialization; instead the program will call a debugger library routine to request debugging services from a particular instance of a distributed debugger. A program can request debugging services for itself or for another program.

One of the major extensions to the distributed debugger that was needed to support the debugging of DB2.TM./CS external programs is the herein described "Dynamic Connection" component. This component enables an application program to locate a distributed debugger front-end in a distributed environment at run-time and to send it a message requesting debugging services. The debugger will then attach a back-end (monitor/controller) to the process for which debugging services is requested.

Architecture of the Invention

The following are definitions of various terms that will be used to describe this invention:

    ______________________________________
    DEBUGEE        A program that is to be debugged.
    DEBUGGER SERVER
                   A program that provides debugging
                   services (e.g., a distributed
                   debugger front-end).
    DEBUGGER CLIENT
                   A program that sends a request to a
                   debugger server to start a debugging
                   session on a debugee. The debugee can
                   be the debugger client itself, or another
                   program running anywhere on the
                   network.
    MONITOR/CONTROLLER
                   A program that is attached to the debugee
                   by the debugger server to monitor and
                   control its execution and read and write
                   state information (e.g., a distributed
                   debugger back-end).
    ______________________________________

    ______________________________________
    CREATEREGISTEREDSOCKET
                     Create a socket and add its
                     socket address to the tool
                     locator registry.
    CLOSEREGISTEREDSOCKET
                     Close a socket and delete its
                     socket address from the tool
                     locator registry.
    STILLALIVE       Inform the tool locator that the
                     debugger server is still available to
                     provide debugging services.
    ______________________________________

    ______________________________________
    BEGINSEARCH    Begin a search of the tool
                   locator registry to locate a
                   debugger server.
    FINDNEXT       Get the socket address of the
                   next debugger server that matches
                   the given specification.
    ENDSEARCH      End the search of the tool
                   locator registry.
    ______________________________________

    ______________________________________
    ERROR.sub.-- STATUS.sub.-- OK
                         normal completion
    NO.sub.-- TOOL.sub.-- LOCATOR.sub.-- HOST
                         The environment
                         variable
                         TOOLLOCATORHOST
                         is not set.
    TOOL.sub.-- LOCATOR.sub.-- NOT.sub.-- RESPONDING
                         The tool locator is
                         not responding.
    ______________________________________

    ______________________________________
    ERROR.sub.-- STATUS.sub.-- OK
                         normal completion
    NO.sub.-- TOOL.sub.-- LOCATOR.sub.-- HOST
                         The environment
                         variable
                         TOOLLOCATORHOST
                         is not set.
    TOOL.sub.-- LOCATOR.sub.-- NOT.sub.-- RESPONDING
                         The tool locator
                         is not responding.
    INVALID.sub.-- SOCKET
                         The specified
                         socket is not valid.
    ______________________________________

    ______________________________________
    ERROR.sub.-- STATUS.sub.-- OK
                         normal completion
    NO.sub.-- TOOL.sub.-- LOCATOR.sub.-- HOST
                         The environment
                         variable
                         TOOLLOCATORHOST
                         is not set.
    TOOL.sub.-- LOCATOR.sub.-- NOT.sub.-- RESPONDING
                         The tool locator
                         is not responding.
    INVALID.sub.-- SOCKET
                         The specified socket
                         is not valid.
    ______________________________________

    ______________________________________
    ERROR.sub.-- STATUS.sub.-- OK
                         normal completion
    NO.sub.-- TOOL.sub.-- LOCATOR.sub.-- HOST
                         The environment
                         variable
                         TOOLLOCATORHOST
                         is not set.
    TOOL.sub.-- LOCATOR.sub.-- NOT.sub.-- RESPONDING
                         The tool locator
                         is not responding.
    ______________________________________

    ______________________________________
    ERROR.sub.-- STATUS.sub.-- OK
                         normal completian
    NO.sub.-- MORE       No more debugger
                         servers can be found.
    NO.sub.-- BEGIN.sub.-- SEARCH
                         A call to BeginSearch
                         must be made before
                         calling FindNext.
    NO.sub.-- TOOL.sub.-- LOCATOR.sub.-- HOST
                         The environment
                         variable
                         TOOLLOCATORHOST
                         is not set.
    TOOL.sub.-- LOCATOR.sub.-- NOT.sub.-- RESPONDING
                         The tool locator
                         is not responding.
    ______________________________________

    ______________________________________
    ERROR.sub.-- STATUS.sub.-- OK
                         normal completion
    NO.sub.-- TOOL.sub.-- LOCATOR.sub.-- HOST
                         The environment
                         variable
                         TOOLLOCATORHOST
                         is not set.
    TOOL.sub.-- LOCATOR.sub.-- NOT.sub.-- RESPONDING
                         The tool locator
                         is not responding.
    NO.sub.-- BEGIN.sub.-- SEARCH
                         A call to BeginSearch
                         must be made before
                         calling EndSearch.
    ______________________________________

    __________________________________________________________________________
    SEARCHCRITERIA      A string that contains the search criteria
                        described above. If NULL is specified, then the
                        current value of the DEBUGSEARCHCRITERIA
                        environment variable will be used.
    INETADDR            The internet address of the machine where the
                        debugee is running.
    USERID              The user ID that the debugee is running under.
    PASSWORD            The password of the user ID that the debugee is
                        running under.
    ADDRSPACEID         The address-space ID (i.e., UNIX .TM. process ID)
                        that the debugee is running under.
    THREADID            The thread ID that the debugee is running
                        under.
    INSTRADDR           The instruction address where the debugging
                        session should begin. If zero is specified
                        then the current instruction address of the
                        debugee is used.
    DBGSERVARGS         is a string that can contain arguments for the
                        debugger (e.g. where to find source code).
    STATUS              a pointer to an int where the status code is
                        returned. The values returned will be one of:
    ERROR.sub.-- STATUS.sub.-- OK
                        normal completion
    DBG.sub.-- NO.sub.-- DEBUGGER.sub.-- SERVER.sub.-- FOUND
                        No debugger server found
                        that matches the
                        specified search
                        criteria.
    DBG.sub.-- DEBUGGER.sub.-- SERVER.sub.-- REJECT
                        The debugger server has
                        rejected the request for
                        debugging services.
    __________________________________________________________________________

    __________________________________________________________________________
    SEARCHCRITERIA      A string that contains the search criteria
                        described above. If NULL is specified, then the
                        current value of the DEBUGSEARCHCRITERIA
                        environment variable will be used.
    DBGSERVARGS         is a string that can contain arguments for the
                        debugger (e.g. where to find source code).
    STATUS              is a pointer to an int where the status code is
                        returned. The values returned will be one of:
    ERROR.sub.-- STATUS.sub.-- OK
                        normal completion
    DBG.sub.-- NO.sub.-- DEBUGGER.sub.-- SERVER.sub.-- FOUND
                        No debugger server
                        found that matches
                        the specified search
                        criteria.
    DBG.sub.-- TOOL.sub.-- LOCATOR.sub.-- FAILURE
                        A call to the tool
                        locator failed.
    DBG.sub.-- NO.sub.-- TOOL.sub.-- LOCATOR.sub.-- FOUND
                        No tool locator found.
    __________________________________________________________________________

• Inventors
  Meier, Michael Stephen; Pan, Hsin;
• Assignee
  International Business Machines Corporation (Armonk, NY)
• Published
  May-2-2000
• Current US Classes:
  707/10
  714/38
  714/45
  717/124
  718/100
• Application #
  606166
• International Classes
  G06F 017/30
• Field of Search
  395/704 395/183.14 395/672 395/709 714/38 714/45 707/10 709/100
• Examiner
  Black; Thomas G.
• Agent
  Gates & Cooper
• US Patent References:
  5127013
  5179702
  5319645
  5361352
  5371746
  5404523
  5410648
  5493675
  5771385
  5781778
  5787245
  5794046
  5794047
  5802371
  5815653
  5901315