| Navigating Source Code | Customizing Your Environment | |
Mainframe Express provides a very powerful editing and debugging environment.
When you are debugging an application, you see the source code of each program displayed in a window. When you debug the code, each line of the source is highlighted in turn as each statement is executed, showing the effect of each statement. You can control the pace at which the program executes and interrupt execution to examine and change data items.
The features available during debugging include:
CALLs and PERFORMs
that are currently active
There are a number of ways to debug code, such as compiling the source yourself first, letting it happen automatically or making available the necessary files created during an earlier compilation. For more details see the sections Debugging Programs in Different Ways, Automatic Debugging when the Application Fails and Files Needed for Debugging.
You can use Micro Focus Mainframe Express and Net Express together to maintain and debug applications that have a distributed client component and a mainframe component. For more information see the section Debugging Distributed Applications.
Although the majority of Mainframe Express's features help you to work with mainframe-based applications, there are some features that you might need to use if you are writing or maintaining PC-based applications. For more information see the section Debugging Non-mainframe Applications.
Note: If you have a project created and built using Mainframe Express 1.1, and you open it in Mainframe Express 2.0, you will see that all COBOL programs have their status shown as "Out of Date". You can in fact run the application without rebuilding, but the Mainframe Express 1.1 debug information files are in the wrong format for Mainframe Express 2.0. This means that if you want to debug a project built using Mainframe Express 1.1, you must first rebuild it.
There are a number of ways to execute all or part of a program, one step at a time or at full speed. The following list outlines the techniques you can use. See the online help for more information.
STOP
RUN statement
PERFORM range or subroutine that includes the current
execution point. Execution halts on the statement after the end
of the PERFORM range or subroutine.
Breakpoints enable you to interrupt execution anywhere in the program. Standard breakpoints halt execution on the statement you choose. Advanced breakpoints are for halting or adjusting the execution of the program under conditions that you specify. You do not need to wait until you are about to debug a program before setting breakpoints; it is more convenient to set them while you are writing or changing the code than to search for the right place later.
Different types of breakpoint enable you to perform the following tasks:
See the online help for more information.
You can move around a program without executing any code in a number of ways. See the online help for information on how to perform these tasks.
The cursor moves to the statement that is the next to be executed and this statement is highlighted.
The execution point moves without executing any code and the new execution point is displayed as the highlighted line. The execution point moves to the next physical statement in the file as opposed to the next logical statement. For example, skipping the last line of a paragraph moves to the next line in the file, rather than returning to where the paragraph was called and moving to the line after the call.
The current section or paragraph
invoked with PERFORM, is exited without executing any
remaining code. The current execution point moves to the first
executable statement after the section or
paragraph and this statement is highlighted.
The execution point moves to the new statement without executing any code and the new statement is highlighted accordingly. You can skip to a statement within the current program only.
Mainframe Express provides a variety of ways to examine data items while you are debugging a program.
For example, you can display the current value of a data item and then change it before you continue testing the program with the new value. You can also watch the value of data items continuously, choosing whether to monitor a number of items in a list or in their own monitor windows.
There are a number of ways to display the value of a data item, but among the quickest ways are to:
and type the
data item's name, or part of its name and click Suggest
You can display the name and value of a data item in the Examine window. Some of the ways you can manipulate items are to:
and
The Watch list permanently displays a list of the data items you choose and their values. Among other things, you can:
Each individual monitor that you create shows the value of one data item. You can also:
As you debug an application that contains a number of subprograms, it is easy to lose track of exactly which programs have been loaded. Mainframe Express can provide this information for you in the Loaded Program list. The Loaded Program list is especially useful if you have specified that you want to recycle windows, resulting in previously loaded programs not being visible.
For each loaded program, the Loaded Program list shows the following information:
The Loaded Program list appears in a movable, dockable window beneath the main editing window.
If you set a breakpoint on a line, when execution halts on the
breakpoint you might not be sure of the path that the application took to
arrive at that line. Mainframe Express provides you with the Call/Perform
stack (accessed on the View menu), which shows all of the CALLs
and PERFORMs currently active.
You see the target section of each active CALL or PERFORM
listed, along with the source file containing that section.
The Call/Perform stack appears in a movable, dockable window beneath the main editing window.
Note: If you select Show system programs in call stack on the Debug Options dialog box, the Call/Perform stack includes information about a number of Mainframe Express system modules.
Mainframe Express includes some features specially designed to help you ensure that your applications meet the demands of the new millennium. These features are as follows:
In some development scenarios, you might want to be able to test an application with a variety of different dates to see the effect that the change in date has on the application's behavior. For example, if you are concerned about how an application might handle the move into the next millennium, you would want to test its behavior in 1999, the year 2000 and beyond.
Mainframe Express includes a utility called DateWarp that enables you to change the current date dynamically for an application. You can specify the date either before you start debugging the application or even while debugging it. The date you specify is used whenever your application requests the current date from the system, for example, by using the syntax:
ACCEPT data-name from DATE
Mainframe Express saves any date that you set for an application and uses it the next time you debug the application using the same project.
For further information look up DateWarp in the online help index.
Some of the software in the range of SoftFactory/2000 solutions includes the ability to export information that you can subsequently import into Mainframe Express while debugging your year 2000 applications. The SoftFactory/2000 information you can import into Mainframe Express is contained in tag files (.poi point of interest files) that are exported from Revolve.
When you generate a .poi file, one .poi file is created for each program in the current project. Each .poi file contains information about any lines in its associated program that contain points of interest. A point of interest is a line of code that may require modification in order for it to work successfully after the year 1999. In Mainframe Express, when you load a program that has an associated .poi file, the .poi file loads automatically with all points of interest highlighted by a bomb icon in the prefix area.
Contact your MERANT International sales representative for more information on the SoftFactory/2000 range of year 2000 solutions.
Before debugging a program, you must compile it. Then when you step or run the program, the program is automatically debugged. Alternatively, you can start debugging the program yourself, which is useful if you want to set up data monitors while stepping or running through the program.
You can also pass parameters to a program you want to debug. You can either specify them as part of the project, so that they are used by default whenever you debug the program, or you can specify the command line with which to start a debugging session.
The debugging of a project stops automatically when necessary, such as when you rebuild the program or open a different project. Alternatively, you can stop debugging the program yourself.
When you want to debug a program again using the same parameters as before and with the data items reset to their original values, you stop debugging and then start debugging again in the same way as before.
You can arrange for an error in your application to trigger the debugging features of Mainframe Express automatically. There are two features available:
You can cause just-in-time debugging to be triggered at a specific
point in your code by using the syntax:
CALL "CBL_DEBUGBREAK".
You can produce a core dump even when you don't have Mainframe Express installed. This is useful when you are debugging a released application on site and you don't have the Mainframe Express development environment installed.
As with just-in-time debugging, you must have the source files and the .idy files to be able to view the core dump. If you do not have the required files, you are given the name of the source file or program where the error occurred.
Before you start debugging a program you must have compiled it. When you compile a COBOL program, the Compiler creates:
You can debug any subprograms that the main program calls, but these must also be compiled and must have their dictionary files available. Any called programs without dictionary files run at full speed, without interruption. Control returns to the debugger only when the called program calls or returns to a program that does have dictionary files.
You can use Micro Focus Mainframe Express and Net Express together to maintain and debug applications that have a distributed client component and a mainframe component, known as distributed applications. A typical development scenario in which you would want to run the two products side-by-side is where you have written a graphical front-end that runs on PCs, for a mainframe-based system that uses CICS to process large numbers of transactions. You now need to ensure that the new distributed client program and the mainframe-based system work together correctly. See the online help for more information.
Your system administrator is responsible for preparing the PC or PCs that you use for debugging distributed applications, and for ensuring that they can communicate; see the chapter Using Mainframe Express with Distributed Applications in your Administrator's Guide.
This section describes the different procedures you need to perform when working with a non-mainframe application.
Mainframe Express has been designed to offer you as much assistance as possible for maintaining and developing mainframe-hosted applications. In some cases, however, you may have some non-mainframe support utilities to migrate to Mainframe Express. To meet this need Mainframe Express provides some extra functionality.
Note: If you want to develop any non-mainframe programs, you should use the alternative solution, Net Express. See your MERANT International sales representative for information on Net Express.
The following steps are in addition to or different from the steps you perform when working with mainframe applications:
Notes:
Copyright © 1999 MERANT International Limited. All rights reserved.
This document and the proprietary marks and names
used herein are protected by international law.
| Navigating Source Code | Customizing Your Environment | |