This chapter provides detailed information about using the COBOL Compiler provided with Mainframe Express.
You can select one of the following types of compilation:
Both types of compilation check the program's syntax and both can be used for testing and debugging.
This type of compilation checks the program's syntax and creates an intermediate code file with the extension .int. Intermediate code files compile quickly and are smaller than optimized code files.
Intermediate code compilation is set as the default but you can select it specifically by ensuring that Create Optimized Code on the COBOL page of the Build Settings for Projects dialog box is unchecked.
This type of compilation also produces a dictionary file with the extension .idy for use with the debugger.
This type of compilation checks the program's syntax and generates an optimized code file, that is, a file containing native machine code. Optimized code files have the extension .gnt and are often referred to as "jint" files.
Optimized code files compile more slowly and are larger than intermediate code files. They are optimized for speed of execution and hence are useful if the program you are debugging is large or has few breakpoints.
Some debugging features are not available for use with optimized code files:
To select an optimized code compilation, check Create Optimized Code
on the COBOL page of the Build Settings for Projects dialog box.
Note: You should not use Run Thru and Run Return when you are debugging generated code files which have been compiled with a mainframe dialect. This is because these dialects have OS/VS-style PERFORMs which invalidate these functions. This is also true for the COBOL for MVS dialect even though the compiler reports that PERFORMs of type COB370 are being used.
You can use directives to control the way the Compiler behaves: what output it produces, what code is compiled and how the compiled code behaves when it runs. For normal operation you need no more than a few directives. Most of the time, you can use the default values.
Note that setting some directives affects the default settings of other directives. For example, setting one directive might automatically unset another directive.
Directives can be set in a variety of ways:
You can set directives in the Development Environment simply by making selections on the Build Settings dialog box, at either project or program level. These appear in Build Settings on the General page.
You can also specify directives in Additional Directives. As you type into Additional Directives, the directives you add appear in Build Settings.
Directives set at project level automatically apply to programs within the project, unless you override them at program level.
For a list of Compiler directives, click Help Topics on the Mainframe Express Help menu, then on the Contents tab click Reference, Development Environment, Compiler Directives.
You can also set directives in the program source code by using
statements. Use these if your program is affected by particular
circumstances, such as needing a specific currency symbol that none of the
other programs in an application needs. If you want the
statements to take effect, you must:
DIRECTIVES-IN-COMMENTas an additional directive on the Build Settings dialog box
$SETstatement is in a comment
$SETdirectives at compilation time
$SETstatements. They can precede or follow other
$SETstatements but must come before any other statements.
$SETstatements, the directive affects compilation from that point onward
The Compiler processes the directives set in the IDE first and then any
$SET directives. If a directive is specified more than once, the
Compiler uses the last setting.
Unless you specify otherwise, the Compiler uses its default settings and compiles your program without any intervention. However, you might want to relocate the copybooks that your program refers to by overriding the default folders specified in the Workgroup view. See the chapter Workgrouping in your User's Guide for more information.
There are two important setting which you may want to change before starting to compile your programs:
Before compiling, you can choose whether or not Mainframe Express should scan for certain OS/VS keywords. Scanning enabled is the default.
The following table shows the resulting changes of dialect if any of these keywords are found and scanning is enabled:
|CURRENT-DATE||Changed to OS/VS|
|EXAMINE||Changed to OS/VS|
|EXHIBIT||Changed to OS/VS|
|FILE-LIMIT||Changed to OS/VS|
|FILE-LIMITS||Changed to OS/VS|
|POSITIONING||Changed to OS/VS|
|TRANSFORM||Changed to OS/VS|
|TIME-OF-DAY||Changed to OS/VS|
|REMARKS||Changed to OS/VS unless it finds:
|01 Data-name COPY||Changed to OS/VS|
|END-IF||Reset to the project default|
|END-PERFORM||Reset to the project default|
|INITIALIZE||Reset to the project default|
override the other keywords; if any of these is found the dialect is reset
to the project default.
If scanning is turned off the dialect setting remains unchanged. You can turn scanning for keywords off on the Build page of the General page of the Project Settings dialog box. For further information, click Help Topics on the Mainframe Express Help menu, then on the Contents tab click Development Environment, Working with Projects, Working with Project Settings, How to Turn COBOL dialect checking on .
If your project contains programs that have failed during compilation and you have not changed them, Mainframe Express does not include these programs in subsequent builds and you see a message informing you that these programs have been skipped. This is the default.
You can select to include these failed programs on the Build page of the General page of the Project Settings dialog box. For further information, click Help Topics on the Mainframe Express Help menu, then on the Contents tab click Development Environment, Working with Projects, Working with Project Settings, How to Skip failed programs in a rebuild.
The Compiler checks the syntax of your program and issues error messages (or exit codes). These messages are displayed in the Output window, from where you can get online help for the error in question or move the cursor to the line in the source that caused the error.
The exit code values returned by the COBOL Compiler are classified
according to their severity as follows:
|Exit Code Return Value||Severity Code||Description|
|16||U||Unrecoverable - Indicates a fatal error|
|12||S||Severe - The Compiler was unable to correct an error. Compilation continues excluding the statement at fault.|
|8||E||Error - The Compiler tried to correct an error|
|4||W||Warning - Flags a statement which is syntactically correct but may contain an error|
|0 through 3||I||Informational - Draws your attention to a part of your source code|
The Compiler returns a value to the operating system to show the most severe type of message issued.
If you have an application or utility that you do not intend to run on the mainframe, you can specify that it uses the non-mainframe dialect in order to make use of extensions to the COBOL language. These extensions provide additional functionality to make it easier to write programs that are only intended to run on a PC.
One set of extensions that the non-mainframe dialect enables is the use of object-oriented COBOL syntax, as defined in our extensions to the COBOL language. However, although the Compiler in Mainframe Express does not return syntax errors when it encounters this object-oriented COBOL syntax, such code produces run-time system errors if you try to debug it.
If you want to develop applications that make full use of our
object-oriented extensions to the COBOL language you should use Net
Express. See your sales representative for more information on Net
Copyright © 2001 Micro Focus International Limited. All rights reserved.
This document and the proprietary marks and names used herein are protected by international law.