Browse Prior Art Database

Debugging One Job From Another Job

IP.com Disclosure Number: IPCOM000101880D
Original Publication Date: 1990-Sep-01
Included in the Prior Art Database: 2005-Mar-17
Document File: 3 page(s) / 124K

Publishing Venue

IBM

Related People

Gordhamer, SL: AUTHOR [+5]

Abstract

A new debugging environment for the AS/400* has been created, allowing one job to be debugged from another job. This allows a batch job to be debugged from an interactive job giving the user all the features of an interactive debugger while debugging the batch job. All debugging commands are entered at the interactive job. All responses from the debugger are displayed at this job. However, the commands act on the batch job being debugged.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 51% of the total text.

Debugging One Job From Another Job

       A new debugging environment for the AS/400* has been
created, allowing one job to be debugged from another job. This
allows a batch job to be debugged from an interactive job giving the
user all the features of an interactive debugger while debugging the
batch job.  All debugging commands are entered at the interactive
job.  All responses from the debugger are displayed at this job.
However, the commands act on the batch job being debugged.

      The debugging of one job, the DEBUGGED JOB from another job,
the DEBUGGING JOB is implemented by the use of EVENTS. An event is
similar to an interrupt, in that it will interrupt a running program.
However, there are several characteristics of the event that makes it
more suitable for this debugger:
 -  An event can be sent to a specific job on the system.
 -  A job can monitor for events sent to it or ignore the events.
With each event type, the job specifies an event handler program.
When the event is received, the program currently running in the job
is interrupted while the event handler runs.
 -  A job can wait on an event.  A running program will issue the
wait request and will then be suspended until the event is received.
 -  Data can be sent with an event.  This data can be used by the
event handler program or by the program that waits for an event.

      To allow the debugging of one job from another job, the
debugger is divided into two sets of programs.  Some programs, which
get input from the user and display data to the user, run in the
debugging job.  Other programs must run in the debugged job, as they
can act on the programs in that job.  Some examples of what must be
done by programs running in the debugged job are:
   setting breakpoints (places where the debugged
   program is to stop)
      -  getting a value of a program variable
      -  changing the value of a program variable
      -  starting a debugged program that has been stopped

      See the figure for a depiction of how these programs interact.

      When a user issues a debugger command in the debugging job, an
appropriate debugger program is called.  This program does what it
can in the debugging job, but eventually something needs to be done
in the debugged job. When this is necessary, the program sends an
event to the debugged job, passing it information on what needs to be
done in the debugged job.  It then waits for a reply event from the
debugged job indicating that the request was performed and then
displays the necessary information for the user.

      The debugged job monitors for events from the debugging job.
When such an event is received, the debugged job is interrupted while
the event handler runs.  This event handler then performs the
required action that was requested by the debugging job.  The event
handler then sends a reply event back to the debugging job and exits,
allowing the debugged...