Tip:
Highlight text to annotate it
X
Introducing the Rational Developer for System z
integrated debugger. Rational developer for System z
(RDz) and the debug perspective are built on the Eclipse
framework which enables the display of multiple views,
tabs and perspectives. This is an example of the debug perspective
that will be covered in this demo.
This is the default out of the box debug perspective
that you can customize according to your preferences.
Notice that we have two perspectives open. The debug perspective that we're in
now and the Remote System Explorer which displays your host network
and files. A perspective is made up of a group of views
and if you select different tabs you'll see different views.
You can choose to run JCL in the background or within the debug perspective.
To submit a JCL job, begin in the remote system explore perspective.
Double-click on the file to open it in the editor,
then type 'sub'
in the command line.
When you submit a JCL job you'll be prompted to open the debug perspective.
The debug perspective opens. Another option is to right-click on a JCL file
in the Remote System Explorer View and select submit.
One of the key features of this debugger
is that you have full access to the feature-rich, language sensitive COBOL
editor integrated with RDz.
Notice the dug icon that
indicates you are in debug. The debug view in the upper left
shows the host information.
Normally a program just runs from beginning to end
but the debug view enables you to see exactly what it's doing
by stepping through a line at a time. Step over will execute the statement
and go on to the next one. You can single step through
a program
or and a break point so that it runs and stops at a certain location.
Double click on the column to add or remove a break point.
At the break point you can step into the program call
for more details or select step over to execute the code
and move on to the next statement.
Notice the multi-color highlighting which is a result of
integrating with the RDz editor that supports COBOL syntax.
It makes it much easier
to quickly scan and navigate your code.
Another great feature is that the information about COBOL is being parsed
as part of RDz, so if you select a variable
you can open the declaration and go directly to the source.
Because it's so closely integrated with RDz
the debugger offers far more features than your typical debugger.
Right click on the variable to open the declaration.
The arrow points to the line that you're about to execute
so even if you move your cursor all around to check variables,
breakpoints, et cetera, you can always see the line that about to execute next.
Notice the value of 'int' initially contains nothing.
But once you step over and move farther down in the program
'int' contains the number 00012.
Another feature is that you can right click on a variable
and select show all the occurrences of that variable
in your program. The results are displayed in the search
view at the bottom, and you can see all the places that variable was used.
Select any variable and it immediately locates the code
and opens it up in the editor for you to view. Tied in closely with the editor
is the Outline view. The Outline view is ideal for navigating a program.
You don't have to use find to locate key parts of the program -
you can just use the outline view to navigate.
Integration with RDz also enables the debugger
to use the Program Control Flow view to navigate your COBOL source.
The variables view shows information about the variables
that are relative to the line in the program that you are currently on.
You can filter the variables and choose to show
everything or just variables within the relationship to the current line.
By default the variables are displayed in their natural form
but you can change the variable format at any time. For example
you could change the variable to display the hexadecimal format
to see a hex representation of the contents of the variable.
You can also view much more complex variable types.
For example the employee name variable is made up of multiple values.
When you open the declaration for employee name you'll see it is made up
of two parts;
firstName and lastName.
And the first few elements are conveniently displayed
without having to expand it.
If there are variables that you are interested in watching all the time,
you can right click on them and select 'Monitor Local Variable'.
and they will be moved to the Monitors view.
These monitors will now be part of the program all of the time
until you modify it. In fact, even if you stop and restart the program
they will remain in place.
At first the variables are not allocated.
You need to step to the breakpoint in the program.
Notice the variables contain values now.
The values and breakpoints are remembered. The Monitors
view shows any places in the source where monitor expression has been
selected.
It allows you to monitor particular values at every point
a break occurs. It will also allow users to change the values at those points.
You can choose one of your complex variables
and select 'Monitor a node' in the Monitors view.
If you're in the variables view and want to monitor something,
simply right click and select 'Monitor Local Variable'
and it will move into the monitors view.
Toggle this icon on and off to show declared type names.
The breakpoints view shows you where all the program breakpoints are.
Breakpoints are places in the program that you want to stop.
Just double click to add a breakpoint. Every breakpoint that you add in the
editor view also appears in the breakpoint view.
If you double click on a line, a line breakpoint is
automatically added. Then you can edit them by right-clicking
and opening the menu.
Notice these are all line breakpoints. In the breakpoints view you can add all
different types of breakpoints.
An Address breakpoint is an instruction address
that you want to stop on. An Entry breakpoint is a particular
entry you want to stop on, for example another program or a subroutine.
Line is just another way of adding a line breakpoint, although normally
you would add them in the editor. Unload breakpoint allows you to stop whenever a
module is loaded; for example a dynamically linked library.
An asterisk will cause it to stop on
anything that's loaded,
or you could type 'ABC' and it will stop at any program
that begins with ABC. The integrated debugger
also allows you to enter a label or description that persists across the
debug session, so that the user can annotate meaning
to a particular breakpoint - for example a
note to indicate where an error occurs.
Monitor memory is another key feature of the new debugger.
Right click to select it.
Monitor memory allows you to show the memory
in different formats, called 'renderings'.
This display is in raw hex.
Next we're going to demonstrate code coverage. When you run code coverage
it is just like debugging, except you add a switch that tells the program to run
code coverage.
We'll comment out this call to show you how it works.
Then add CC for code coverage to the JCL file
and submit the job. Code coverage uses debugging technology
to track all the executed lines in a program and show you which ones were hit
and which ones were not. Notice in this case eighty-three percent of the
executable lines were covered, so out of a total of 43 lines
only 36 were actually hit. You can expand the contents for more details.
In this case none of the lines in 'INITTBL'
were executed.
After opening it in the editor, you can see that this call was commented out.
If you return to the previous command you can double click to open that
section of the program
and scroll down to see where the call didn't execute. Notice the lines are all
green on the left
until the program reaches the call that didn't execute. The line turns to red
to indicate that it did not execute. If we go back to the program
and remove the comment from the call, save it and resubmit the JCL,
that will rebuild the program so that we can rerun it in code coverage.
This time we have 100 percent success.
The History view lets you track and compare the changes in each of your
sessions.
Another option is to modify the code coverage results,
for example by capturing just function level
versus line level.
When we modify it and resubmit the job -
this time the results only show the functions.
If you remove CC it will run in debug mode,
and if you leave CC in it; it will run code coverage.
This concludes the demo.
Please click on the following links for more information and demos.