System Intelligence

Chapter 1: Compiling COBOL Programs

This chapter provides detailed information about using the COBOL Compiler provided with Mainframe Express.

1.1 Two Types of Compilation

You can select one of the following types of compilation:

• Intermediate code creation
• Optimized code creation

Both types of compilation check the program's syntax and both can be used for testing and debugging.

1.1.1 Intermediate Code Creation

1.1.2 Optimized Code Creation

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:

• You cannot use Do and Breakpoint Do

• You might not be able to continue debugging after a run-time system error

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.

1.2 Setting Compiler Directives

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:

1.2.1 Directives Set in the IDE

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.

1.2.2 Directives Set in Programs

You can also set directives in the program source code by using $SET 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 $SET statements to take effect, you must:

Notes:

• The mainframe environment ignores the $SET directives at compilation time 

• You must set some directives at the start of the program; these are known as initial $SET statements. They can precede or follow other $SET statements but must come before any other statements.

• When you specify a directive on a statement after the initial $SET statements, the directive affects compilation from that point onward

1.2.3 Order of Processing

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.

1.3 Preparing to Compile

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:

• Scanning for the OS/VS dialect

• Skipping previously failed programs

1.4 COBOL Compiler Errors

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:
 

The Compiler returns a value to the operating system to show the most severe type of message issued.

1.5 Object-oriented Extensions in the Non-mainframe Dialect

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 Express.

System Intelligence