| Using Application Server | Compiling Programs | |
This chapter describes the different ways you can package your applications, and describes how the choices you make affect the process of compiling and linking programs.
Throughout the rest of this chapter the word "application" is used to describe the product you want to ship to your users; the word "program" is used specifically to describe the programs that make up an application.
With the Object COBOL system you can:
Each of the options presented here has its advantages and disadvantages.
When you create an application, you need to consider the following:
These considerations affect the way you create your application. For example:
The following sections describe the differences between the executable file types, and between the different methods of packaging your applications.
You can create three different types of executable file:
Intermediate code files and generated code files are proprietary executable files that need access to the run-time system provided with Object COBOL. For information on running these files, see the section Using .int and .gnt Files in an Application.
System executable files are files compiled and linked to create executable files in operating system formats.
For information on compiling programs, see the chapter Compiling Programs. For information on linking programs, see the chapter Linking Programs.
The executable file types are described in more detail in the following sections.
Intermediate code files are created by the Compiler when it checks the syntax of programs. These files are independent of both the chip-set and operating system, and are thus highly portable to other platforms. They cannot be shared between processes; if two different executables call at the same time a subprogram compiled to intermediate code, a separate copy of that subprogram is loaded into each process's virtual memory space, and run.
An intermediate code file is dynamically loaded and interpreted by the run-time system. Because the intermediate code is interpreted by the run-time system, intermediate code files generally execute slower than generated code files or system executable files.
Intermediate code files have the extension .int; for example, myprog.int. The phrase ".int file" is often used as a synonym for the phrase "intermediate code file".
Intermediate code files are created when you check the syntax of your program. Syntax-checking is one of the phases of the compilation process. Programs are compiled using the cob command; see the chapter COBOL System Interface (cob) for details.
Note: The Editor and Animator can call the Compiler to create .int files.
Generated code files are created by the Compiler's generate phase when requested. These files are portable to the same chip-set, but are operating system independent.
Generated code files are typically many times faster than .int files. Generated code files cannot be shared between processes; if two different programs call at the same time a subprogram compiled to generated code, a separate copy of that subprogram is loaded into each process's virtual memory space, and run.
Generated code files have the extension .gnt ; for example myprog.gnt. The phrase ".gnt file" is often used as a synonym for the phrase "generated code file".
Programs are compiled using the cob command; see the chapter COBOL System Interface (cob) for details.
System executable files are not portable, but typically run many times faster than .int files. They can be shared between processes. If multiple copies of the same system executable are run at the same time, the operating system shares the procedural code and creates separate data areas. This includes sharing any COBOL procedural code linked into the system executable.
System executable files do not typically have a filename extension.
On some systems you can create standard shared objects. Check your on-disk documentation. Shared objects typically have the extension .so.
The following table summarizes the differences in the executable file formats available in Object COBOL.
| Executable file format | Filename extension | Advantages | Disadvantages |
| Intermediate code | .int | Used in debugging and testing Quick to create Does not require linking Portable to other processors and operating systems File is smaller than equivalent system executable file |
Executes slowly Not shareable |
| Generated code | .gnt | Code executes quickly Quick to create Does not require linking Portable to other platforms running on a common processor. |
Not shareable File is larger than equivalent .int file |
| System executable code | none | Operating system format Executes quickly Shareable Used for mixed language applications |
Needs linking Can be very large, if using static linking Not portable |
| Shared object | .so | Operating system format Executes quickly Shareable Used for mixed language applications |
Needs linking Not portable Not available on all systems |
As we have seen, there are two ways to package an application:
In many COBOL systems, subprograms and support modules must be linked to your programs by a linker utility after compilation. In Object COBOL, linking is unnecessary, though it is available as an alternative method (see the section Linking Programs later in this chapter for an overview of linking).
Using Object COBOL you can:
These abilities are provided by a run-time system that contains the run-time support routines that your COBOL programs might need. The run-time system provides dynamic loading which loads and executes your program, and loads COBOL subprograms and support modules as your application needs them.
To make use of the dynamic loader, you must compile your programs to intermediate or generated code. For example, typing:
cob -u myprog.cbl
creates myprog.gnt.
.int and .gnt files do not have to be linked to be able to run. However, applications containing .int or .gnt files require a run-time system with a dynamic loader. Object COBOL provides a default run-time system, $COBDIR/rts32. A trigger program, cobrun, is also provided to execute .int and .gnt files. You can create your own trigger program, if required. For example, if your .int or .gnt files call C functions, you can create a system executable file that contains the C functions, and the run-time system. See the Linking chapter for details.
Figure 3-1: Trigger executable
Micro Focus supplies a trigger program called cobrun that can be used to trigger .int and .gnt files. For example, to run myprog.gnt using cobrun trigger, type:
cobrun myprog.gnt
See the chapter Running for details on using cobrun.
You can create your own executable file to trigger your application if required. See the chapter Linking Programs for details.
The UNIX system provides basic functionality to build and execute programs. Your COBOL system exploits this and provides additional COBOL-specific functionality.
If you want to create applications in industry standard executable formats you need to link the programs in your application using cob. The cob command can be used to link a program to the various system or language support routines and possibly called subroutines that are needed at run time. It can be used to build an executable object file using the system linker to link all the required run time procedure references to an instance of the required code.
You can create two types of linked executable file: a statically-linked executable, or a dynamically-linked executable. All UNIX systems enable you to create statically-linked executable files, but not all enable you to create dynamically-linked executables.
The main advantage of using a dynamically-linked application over a statically-linked application is that code can be shared between several applications. With static linking, code is shared only between different processes or users using the same application. See the chapter Linking for more details.
Copyright © 1998 Micro Focus Limited. All rights reserved.
This document and the proprietary marks and names
used herein are protected by international law.
| Using Application Server | Compiling Programs | |