Patent Application
20080155505
1. Field
This disclosure generally relates to testing software applications for errors. More particularly, the disclosure relates to an interactive debugging session.
2. General Background
Software applications may encounter errors (also called “bugs”) that lead to a number of problems, e.g., incorrect modification of data, system crashes, slower performance, etc. Software developers often attempt to discover as many bugs as possible during the development of the software application to eliminate the presence or at least minimize the number of bugs in the software application prior to release of the software application to the end user. A debugger is a software tool that a programmer utilizes to “debug” a program, i.e., find the bugs in a program. The debugger runs concurrently with the execution of the program and allows the programmer to monitor and control that execution. For instance, the programmer can monitor a particular variable or memory register to see what changes take place during execution. Further, the programmer can insert “break points,” i.e., locations within the source code at which the debugger can pause execution of the program. The programmer can attempt to make sure that the program is executing properly at particular locations. Accordingly, the programmer can then narrow down potential locations in the source code at which bugs are located.
However, errors may occur within a program after its release because of bugs that were not found beforehand. The programmer then needs to further debug the program. Once again, the programmer can utilize the debugger to debug the program. Realistically, the process of debugging may continue well after the release of the program until the program no longer becomes useful or is improved upon.
Accordingly, the process of debugging can be a long an arduous task that often involves teams of programmers, especially with a larger software application. As a result, multiple programmers should ideally be able to debug the same program at the same time. If only one programmer at a time is allowed to make changes to the code, the efficiency of multiple programmers debugging is significantly, if not completely, hampered.
Current systems do not provide a seamless approach that allows multiple programmers to debug the same code at the same time. Additional infrastructure is utilized on a case-by-case basis and often requires specific implementations such as the granting of special system privileges or rebuilding an application. For instance, a privilege is utilized in many systems to allow for a change to an address for an input/output (“I/O”) device for which a debugging session is to occur. A normal programmer does not usually have such a privilege and, therefore, wastes time attempting to obtain such an address change from someone who does have the privilege. Further, the location of the I/O device is usually dependent on the software application. In other words, an I/O device address may be utilized irrespective of the programmer that is utilizing the I/O device at a given time. Therefore, if a first user initiates a debugging session at an I/O device, the debugging session occurs at the I/O device currently on record. If a second user initiates another debugging session at the same time, the additional debugging session will not be successfully established because the I/O device is currently in use by the first user. If the second user initiates a debugging session after the first user completes his or her debugging session, the debugging session is still established at the I/O device of the first user. This may be inconvenient for the second user, who may want to utilize a different I/O device than the first user. The software application may have to be rebuilt to allow for the second user to have a debugging session of his or her own. The utilization of additional infrastructure on a case-by-case basis is an inefficient approach because one programmer may have the resources for a particular infrastructure while another programmer may not have such resources. As a result, current systems are not user friendly, which is an attribute that a debugger should ideally have to allow for easy navigation by programmers.
In one aspect of the disclosure, a computer program product is disclosed. The computer product includes a computer useable medium having a computer readable program. The computer readable program when executed on a computer causes the computer to receive user specific data for a debugging session. The user specific data includes a location for an input/output device. Further, the computer readable program when executed on the computer causes the computer to initiate a debugging session at the input/output device specified at the location in the user specific data.
In another aspect of the disclosure, a system is disclosed. The system includes a reception module that receives user specific data for a debugging session. The user specific data includes a location for an input/output device. Further, the system includes a debugging module that initiates a debugging session at the input/output device specified at the location in the user specific data.
In yet another aspect of the disclosure, a method is disclosed. The method receives user specific data for a debugging session. The user specific data includes a location for an input/output device. Further, the method initiates a debugging session at the input/output device specified at the location in the user specific data.
In another aspect of the disclosure, a computer program product is disclosed. The computer product includes a computer useable medium having a computer readable program. The computer readable program when executed on a computer causes the computer to receive user specific data for a debugging session. The user specific data includes a location for an input/output device. Further, the computer readable program when executed on the computer causes the computer to operate a debugging session, at the input/output device specified at the location in the user specific data, of a program concurrently with one or more additional debugging sessions of the software application being operated at one or more additional input/output devices distinct from the input/output device.
In yet another aspect of the disclosure, a computer program product is disclosed. The computer product includes a computer useable medium having a computer readable program. The computer readable program when executed on a computer causes the computer to receive a user specific runtime parameter for a debugging session. Further, the computer readable program when executed on the computer causes the computer to initiate a debugging session based on the user specific runtime parameter.
The above-mentioned features and objects of the present disclosure will become more apparent with reference to the following description taken in conjunction with the accompanying drawings wherein like reference numerals denote like elements and in which:
A centralized and consistent approach can be utilized by a debug engine to present an interactive debugging session. The approach provides a user friendly way for the programmer to specify an I/O device location for the I/O device that the programmer is utilizing to debug a program. Further, a list of programs to be debugged can be provided. In addition, other runtime conditions utilized in the debugging session can be provided. The I/O device location is provided to the debug engine, which can then initiate an interactive debugging session for the user at the I/O device that the programmer is utilizing.
In one embodiment, the programmers initiate the software application 110 prior to debugging so that the respective debug engine can control and monitor the software application 110. Accordingly, the programmers initiate the software application 110 through various middleware components, e.g., middleware A 118, middleware B 120, and middleware C 122, that act as intermediaries to the modules of the software application 110.
Once the software application 110 is invoked, a first programmer, utilizing a first I/O device 102, and a second programmer, utilizing a second I/O device 104, attempt to initiate debugging sessions with the software application 110. The first I/O device 102 can utilize a first debug engine 106 to debug the software application 110 while the second I/O device 104 can utilize a second debug engine 108 to debug the software application 110. However, the debug engines may not be located on the I/O devices. For instance, the debug engines may be located on separate servers from the I/O devices and are responsible for establishing the debugging sessions on the I/O devices. The debug engines should know the locations of the I/O devices in order to establish the debugging sessions. In one embodiment, the first debug engine 106 and the second debug engine 108 accomplish this by communicating with various middleware components, e.g., middleware A 118, middleware B 120, and middleware C 122, that act as intermediaries to the modules of the software application 110. The middleware components can perform tasks such as translating the requests made by the first I/O device 102 and the second I/O device 104 into commands that the software components can understand. However, each middleware component may utilize a different infrastructure for establishing a debugging session with the I/O devices. For example, middleware A 118 may have an infrastructure that grants system privileges to the programmer to specify the location of the I/O device and a list of programs that the programmer is interested in debugging where as middleware B 120 may have a different infrastructure that involves the programmer performing a rebuild after specifying the location of the I/O device and list of programs that the programmer is interested in debugging. As a result, the first programmer and the second programmer utilize knowledge of the different infrastructures for the various middlewares to initiate a debugging session for the software application 110.
The configuration 200 utilizes the centralized runtime environment 202 to request and receive location information for a particular I/O device at which a programmer would like to initiate a debugging session. In another embodiment, the centralized runtime environment 202 also requests and receives a list of one or more programs to be debugged. As will be explained below, in one embodiment, the centralized runtime environment 202 accesses the location information for the I/O device through the software application 110. In another embodiment, the centralized runtime environment 202 accesses a list of one or more programs to be debugged through the software application 110.
Being that the centralized runtime environment 202 can communicate with each of the middleware components, the centralized runtime environment 202 can effectively provide the location information for the I/O device to each of the middleware components, which can then provide the location information for the I/O device to the debug engine. As a result, the debug engine does not need to be concerned with the different nuances of each of the different middleware components that are needed in order to obtain the location information for the I/O device. The middleware components can provide the location information for the I/O device to the debug engine so that the debug engine knows the location of the I/O device at which a debugging session is to be established. For instance, the first debug engine 106 does not need to be concerned with the different nuances of middleware A 118, middleware B 120, and middleware C 122 in order to obtain the location information for the I/O device 102 at which the debug engine 106 is attempting to initiate a debugging session from these middleware components. Rather, the centralized runtime environment 202 can communicate effectively with and provide the I/O device location information to the middleware components. Accordingly, each of the modules of the software application 110 can communicate with the first debug engine 106 to establish a debug session with the first I/O device 102. In another embodiment, a list of one or more programs to be debugged can also be provided by the centralized runtime environment 202 to the middleware components, which can then be provided to the debug engine. Further, the first debug engine 106 can be utilized to monitor and debug the programs on the list. In another embodiment, the list of programs is utilized by a user exit 302, as seen in
As a result, the configuration 200 allows the debug engine 106 to receive the I/O device location information and potentially other runtime information from the middleware components. The debug engine 108 can concurrently receive such information also. Further, the debug engine 106 can query the middleware components during the debug session to receive runtime information. The debug engine 108 can concurrently query the middleware components during the debug session also.
The user file 306 is a data set. In one embodiment, the user file 306 can be utilized on an operating systems such as the z/OS® operating system manufactured by IBM Corporation. In one embodiment, the contents of the user file 306 can be stored in the form of tags. An example of the tag that can be utilized can be seen in Extensible Markup Language (“XML”). For instance, a tag <PGM> can be utilized to indicate a list of programs to be debugged. Further, a tag <TST> can be utilized to indicate a test runtime option, which can contain the I/O device location information. In addition, a tag <RTO> can be utilized to indicate other runtime options. In another embodiment, a utility can be provided to help the programmer create the data set for the user file 306 in a formatted structure.
Prior to debugging, the programmer also builds the software application 110 with a user exit 302 linked into the software application 110. The user exit 302 is a call to an external program 304 that is utilized to provide functionality that is not necessarily intended for the software application 110. In one embodiment, the user exit 302 is built into the software application 110. In another embodiment, the user exit 302 is stand alone.
As an example, the main purpose of the software application 110 may be to provide an ordering system while the external program 304 provides functionality for accessing the user file 306. In one embodiment, the user file 306 may or may not be stored on the same storage medium as the software application 110, but is a distinct file. Accordingly, when the user exit 302 is called, the external program 304 accesses the user file 306 and can retrieve various information, such as location information for the I/O device, from the user file 306. In one embodiment, the user exit 302 contains the naming pattern utilized by the programmer to name the user file 306. The naming pattern can be placed in the user exit 302 prior to the software application 110 being built with the user exit 302. Further, the naming pattern can contain a suitable token that the external program 304 utilizes to substitute with the user identification (“ID”) to invoke the software application 110.
The token is essentially a placeholder. In other words, the user ID is not hard coded into the naming pattern. As a result, when a user would like have a debugging session, the particular user ID of that user can be dynamically substituted for the token to create a unique data set name of the user file 306 for that user. The term dynamic is intended to mean that the software application 110 does not have to be rebuilt each time a user would like to invoke a debug session. Accordingly, multiple users can concurrently debug the software application 110 in an efficient manner by utilizing his or her own I/O device. Having user unique user files allows for multiple users to each have their own debugging sessions.
At the time that the programmer would like to initiate debugging of the software application 110, the programmer invokes the software application 110. During the initialization of the application, the centralized runtime environment 202 calls the user exit 302 to obtain the I/O device location information of the I/O device at which the user would like to initiate the interactive debugging session. Once the centralized runtime environment 202 obtains the I/O device location information, the centralized runtime environment 202 can provide that I/O device location information to the middleware components, as seen in
As shown in
This approach allows for the I/O device location information to be dependent on the user ID, which is unique, rather than the software application 110. When the I/O device location information is dependent on the software application 110, multiple users cannot debug the software application 110 at the same time as the only I/O device location information that would be provided to the middleware components would be the I/O device location information associated with the software application 110. By having user unique I/O device location information, the I/O device location information for each user can be provided to the middleware components to allow for concurrent debugging by multiple programmers. This can be accomplished because each user has a distinct user ID, and therefore, distinct user files are accessed for I/O device location information for each of the programmers. Accordingly, an end-to-end debugging approach is provided that allows multiple programmers to debug the same software application 110 at the same time, even if the software application 110 spans across multiple servers that interact with multiple middleware components.
In another embodiment, the user exit 302 can be a user exit for the centralized runtime environment 202. This user exit utilizes the tagged information in the data set of the user file 306 to filter user programs for debugging. If a programmer is requesting to debug a program that is on the program list in the user file 306, the user exit passes back debug information, which includes the device location information, to the centralized runtime environment 202. If the programmer is requesting to debug a program that is not on the program list in the user file 306, the user exit returns to the centralized runtime environment 202 without any debug information. As a result, that particular program runs without a debugging session.
The process 400 can be utilized for a variety of runtime parameters. In another embodiment, the process 400 receives a user specific runtime parameter for a debugging session. Further, the process 400 can initiate a debugging session based on the user specific runtime parameter.
Further, the process 400 can be utilized to allow multiple programmers to concurrently debug a program. In yet another embodiment, the process 400 receives user specific data for a debugging session. The user specific data includes a location for an input/output device. Further, the process operates a debugging session, at the input/output device specified at the location in the user specific data, of a program concurrently with one or more additional debugging sessions of the software application being operated at one or more additional input/output devices distinct from the input/output device.
Any of the embodiments described above can be utilized in a computer program product, system, or method configuration. Accordingly, a programmer can more efficiently debug the software application 110.
The processor 502 is coupled, either directly or indirectly, to the memory 506 through a system bus. The memory 506 can include local memory employed during actual execution of the program code, bulk storage, and/or cache memories which provide temporary storage of at least some program code in order to reduce the number of times code must be retrieved from bulk storage during execution.
The I/O devices 504 can be coupled directly to the system 500 or through intervening input/output controllers. Further, the I/O devices 504 can include a keyboard, a keypad, a mouse, a microphone for capturing speech commands, a pointing device, and other user input devices that will be recognized by one of ordinary skill in the art. Further, the I/O devices 504 can include a receiver, transmitter, speaker, display, image capture sensor, biometric sensor, etc. In addition, the I/O devices 504 can include storage devices such as a tape drive, floppy drive, hard disk drive, compact disk (“CD”) drive, etc.
Network adapters may also be coupled to the system 500 to enable the system 500 to become coupled to other systems, remote printers, or storage devices through intervening private or public networks. Modems, cable modems, and Ethernet cards are just a few of the currently available types of network adapters.
It should be understood that the method and system described herein can take the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment containing both hardware and software elements. If software is utilized to implement the method or system, the software can include but is not limited to firmware, resident software, microcode, etc.
Further, the method and/or system can take the form of a computer program product accessible from a computer-usable or computer-readable medium providing program code for use by or in connection with a computer or any instruction execution system. For the purpose of this description, a computer-usable or computer readable medium can be any apparatus that can contain, store, communicate, propagate, or transport the program for use by or in connection with the instruction execution system, apparatus, or device.
The medium can be an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system (or apparatus or device) or a propagation medium. Examples of a computer-readable medium include a semiconductor or solid state memory, magnetic tape, a removable computer diskette, a RAM, a ROM, a rigid magnetic disk and an optical disk. Current examples of optical disks include CD-read only memory (“CD-ROM”), CD-read/write (“CD-R/W”) and DVD.
While the apparatus and method have been described in terms of what are presently considered to be the most practical and preferred embodiments, it is to be understood that the disclosure need not be limited to the disclosed embodiments. It is intended to cover various modifications and similar arrangements included within the spirit and scope of the claims, the scope of which should be accorded the broadest interpretation so as to encompass all such modifications and similar structures. The present disclosure includes any and all embodiments of the following claims.
