Data processing: software development – installation – and managem – Software program development tool – Testing or debugging
Reexamination Certificate
2000-02-18
2003-12-02
Ingberg, Todd (Department: 2124)
Data processing: software development, installation, and managem
Software program development tool
Testing or debugging
C717S128000, C717S129000, C717S131000, C709S241000
Reexamination Certificate
active
06658650
ABSTRACT:
FIELD OF THE INVENTION
The invention is directed to debuggers and debugging of computer programs. In particular, the invention is directed to debugging multi-job computer programs.
BACKGROUND OF THE INVENTION
The process of locating, diagnosing and correcting logical errors, or ‘bugs’, in computer application source code is generally referred to as “debugging” in the context of computer programming. A broad array of software designed to assist in debugging has been commercially developed and made available for the purpose of more efficiently troubleshooting programming errors that occur in developing software. Most conventional debuggers allow a computer programmer to conduct a series of commands or tests that reveal information pertaining to the configuration and veracity of a developing program's source code. A typical debug operation consists of a programmer ‘stepping’ through a series of program statements using debug commands to identify and fix encountered errors. While such an undertaking can be time consuming and tedious for a programmer even under ideal conditions, the task of debugging is compounded dramatically when conducted in operating environments where the application being debugged spans multiple jobs that are executing simultaneously.
A ‘job’ refers to a single process, or task, that is performed by a computer. Each job consists of allocated memory known as working storage and one or more execution states known as threads, which follow the control flow of program code saved in working storage. Jobs have unique designators associated with them for the purpose of identifying a particular job. A user who desires to perform a specific computer operation designates the execution path corresponding to the operation, and the associated job is accordingly ‘created.’ A computer processor in turn executes the conjured job, and the user's desired operation is initiated. A computer processor cycles through a sequence of jobs, generally servicing in some capacity each job in the order received. The processor can service a job to various execution states, including terminated (‘killed’), suspended, or actively running jobs. Examples of jobs literally include every definable task which may be performed by a computer, including software initializations, the printing of computer files, and the creation of other jobs, among others.
A typical user's session may require that multiple jobs be concurrently initiated and executed. This is not only due to the increasing volume and complexity of tasks generally performed by computers, but is also because the proper execution of certain, user-designated jobs may be dependent upon the presence of other jobs running in the background. Some languages may also require incompatible operating environments for different aspects of a computer program, necessitating multiple jobs to handle the different operating environments.
Multiple job environments, however, can significantly complicate the debugging process—particularly when certain jobs are not amenable to debugging directly within such jobs. For example, in a scenario where a debug process must be performed on a batch job, it may not be possible to perform debugging directly on the batch job because the batch job may not have access to the user interface of the programmer's terminal, or the user interface may be otherwise occupied or unavailable. In other instances, it may not be practicable to perform a debug process directly within a job when the actual display of information by the job is of concern, e.g., if the job displays graphical information that would be occluded or misaligned due to the display of debug messages.
To address this concern, a number of multi-job environments support the ability for one job, known as a utility job or a service job, to service another job, such that the service job essentially handles user interaction with a debugger during debugging of a serviced job. Although performing a debug operation using such a service operation can help avoid some of the above mentioned pitfalls, there remain inherent obstacles to establishing the necessary communication between service jobs and jobs requiring debugging. In particular, conventional environments often require a request to perform a service operation to provide the identity of the job to be serviced, e.g., by providing a unique job identifier associated with the job to be serviced. However, the job identifier for a job is typically not assigned until after the job is created, or ‘spawned’. As such, whenever it is desirable to debug a job through a service operation, a programmer must be able to gain control of the job to be serviced prior to initiating the service operation.
Control is obtained over a job when execution of the job has been suspended and user interaction with the job is permitted to perform debugging and/or other service operations. One conventional service used to gain control of jobs relies on the use of ‘global breakpoints.’
A global breakpoint is a type of control point that can be set and detected during execution of a computer program to perform a particular debug operation on the computer program. Specifically, a global breakpoint in a computer program causes any active job that uses the computer program to stop when the global breakpoint is encountered by that job. Under ideal circumstances, this mechanism can permit a user to gain control of a job to be debugged, allowing a debugging process to initiate at an appropriate instance in a developing program's source code. However, under normal operating conditions, global breakpoints can significantly degrade the performance and availability of a computer since all jobs that hit the global breakpoint, even those not under debug, will trigger the breakpoint. Furthermore, in single-level store computer environments where multiple users share a common copy of a computer program, a breakpoint in the computer program may be hit by all jobs that use the computer program, regardless of whether the users that own the jobs are actively debugging the computer program.
When a conventional global breakpoint is encountered, execution of the job that hit the breakpoint is suspended, and the encounter is reported to the user performing debugging. If the owner of the job is not performing the debugging, however, the job essentially appears hung or stalled to the owner until it is restarted by the user performing the debugging. As such, global breakpoints can be significantly disruptive in many computer environments.
Therefore, a significant need exists for a manner facilitating debugging in multi-job environments. In particular, a significant need exists for a manner of identifying and gaining control of jobs created in a multi-job environment to facilitate the performance of debugging and other service operations thereon.
SUMMARY OF THE INVENTION
The invention addresses these and other problems associated with the prior art by providing an apparatus, program product and method in which a type of control point, referred to hereinafter as a service entry point, is established in a computer program to trigger under a predetermined set of conditions to facilitate gaining control of a created job in a multi-job environment. Specifically, a service entry point consistent with the invention is triggered when the following conditions are true:
(1) the job within which the service entry point was hit is not currently under debug;
(2) the job has an attribute that is common to another job that established the service entry point; and
(3) there is another job waiting to begin servicing a job having the same attribute.
By conditioning a service entry point on the aforementioned conditions, service operations may be initiated on a created job with significantly less difficulty. For example, as a consequence of a service entry point meeting the aforementioned conditions, the job hitting the service entry point under such conditions may be automatically halted, thereby facilitating the gaining of control of the job. In addition, the pending
Ingberg Todd
International Business Machines - Corporation
Nahar Gamrun
Wood Herron & Evans
LandOfFree
Service entry point for use in debugging multi-job computer... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Service entry point for use in debugging multi-job computer..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Service entry point for use in debugging multi-job computer... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3158498