Data processing: software development – installation – and managem – Software program development tool – Translation of code
Reexamination Certificate
1996-02-23
2001-11-27
Banankhah, Majid (Department: 2151)
Data processing: software development, installation, and managem
Software program development tool
Translation of code
Reexamination Certificate
active
06324683
ABSTRACT:
BACKGROUND OF THE INVENTION
1. Field of the Invention
This invention relates to systems, methods, and programs for utilizing application development tools, and more specifically, for utilizing a debugger to debug external programs such as stored procedures and user-defined functions that are used in database processing systems.
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 transaction, a DB/2 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 transaction, DB2 stored procedure, or DSOM server, the application programs are executed under the control of a software system such as the CICS transactions manager, DB2 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 transaction) to debug.
CICS (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 operating system and OS/2 operating system have similarities in their architecture. Such transaction monitors include CICS/6000, Tuxedo, and Encina, 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/Common-Server for AIX/6000 (DB2/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/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/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) by allowing users to define their own functions implemented in host languages 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.
The first step of creating a UDF, i.e., the specification component, is to register its name and attributes by executing a create function SQL statement. Taking find_string as an example shown below, the specification component is expressed by the following create function statement which specifies that UDF find_string:
takes a LONG V
Fuh You-Chin (Gene)
Meier Michael Stephen
Pan Hsin
Banankhah Majid
Gates & Cooper LLP
International Business Machines - Corporation
Lao Sue
LandOfFree
System, method and program for debugging external programs... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with System, method and program for debugging external programs..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and System, method and program for debugging external programs... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2605992