PreviousUsing Application Server Creating ProgramsNext"

Chapter 3: Packaging Applications

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 Server Express you can create applications that consist of any combination of:

Each of the options presented here has its advantages and disadvantages.

When you create an application, you need to consider the following:

The following sections describe the differences between the executable file types, and between the different methods of packaging your applications.

3.1 Executable File Types

You can create five different types of executable file:

Callable shared objects are executable files in an operating system format that are dynamically loaded by the COBOL run-time system provided with Server Express. For information on using these files, see the section Packaging Applications Using Callable File Formats.

Intermediate code files and generated code files are proprietary executable files that are dynamically loaded by the COBOL run-time system provided with Server Express. For information on using these files, see the section Packaging Applications Using Callable File Formats.

Shared libraries are system linkable files that can be linked into executable files.

System executable files are files compiled and linked to create executable files in operating system formats.

For information on compiling programs, see the chapter Using the Compiler. For information on callable shared objects see the chapter Callable Shared Objects. For information on linking programs, see the chapter Linking to System Executables.

The executable file types are described in more detail in the following sections.

Whichever file formats you use, you will need to ship Application Server with your application. For information on Application Server, see the chapter Application Server.

3.1.1 Callable Shared Object Files

Callable shared object files are in an operating system format. They can be shared between processes; if two different system executables call, at the same time, a subprogram created as a callable shared object, that program is loaded only once and executed when called. The operating system shares the procedural code and creates separate data areas for each process.

A callable shared object is dynamically loaded and executed by the run-time system. Callable shared objects are not interpreted; their execution time is generally quicker than either intermediate or generated code.

Callable shared object files have the filename extension .so; for example, myprog.so.

Callable shared object files are created using the cob -z command; see the chapters COBOL System Interface (cob) and Callable Shared Objectsfor details.

3.1.2 Intermediate Code Files

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 other executable file formats.

Intermediate code files have the filename 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 -i command; see the chapter COBOL System Interface (cob) for details.

3.1.3 Generated Code 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 dependent. 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.

A generated code file is dynamically loaded and executed by the run-time system. Generated code files are typically many times faster than .int files.

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 -u command; see the chapter COBOL System Interface (cob) for details.

3.1.4 Shared Library Files

Shared library files are linked into system executable files. They are loaded when the system executable is loaded and run. They cannot be executed themselves. They can be shared between processes. If multiple copies of the same shared library are used at the same time, the operating system shares the procedural code and creates separate data areas for each process. This includes sharing any COBOL procedural code linked into the shared library file.

Shared library files have the prefix lib, and the extension .so; for example, libmyprog.so. On HP/UX, the extension is .sl.

Programs are compiled using the cob -Z command; see the chapter COBOL System Interface (cob) and Linking to System Executables for details.

3.1.5 System Executable Files

System executable files are in an operating system format. 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 for each process. This includes sharing any COBOL procedural code linked into the system executable.

System executable files are loaded by the operating system, which creates a new process in which to run it. They cannot be called, using the CALL statement, from COBOL.

System executable files do not typically have a filename extension, and are sometimes known as a.out files.

Programs are compiled using the cob -x command; see the chapters COBOL System Interface (cob)and Linking to System Executables for details.

3.1.6 Executable File Types - Summary

The following table summarizes the main advantages of the different executable file formats available in Server Express.

Advantages File-type
Operating system format Callable shared object
System executable
Shared library
Executes quickly Callable shared object
Generated code
System executable
Shared library
Shareable Callable shared object
System executable
Shared library
Used for mixed language applications Callable shared object
System executable
Shared library
Dynamically loaded and only run when called from a COBOL program Callable shared object
Generated code
Intermediate code
Portable to other processors and operating systems Intermediate code
Submodules can easily be replaced without relinking the entire application Callable shared object
Generated code
Intermediate code
Shared library

All of the file formats can be used when debugging a program.

3.2 Creating Applications

As you can see from the sections above, there are many ways to package an application to suit your requirements, using executable files in proprietary and system formats.

Perhaps the best way of packaging an application is, therefore, to create a system executable that is linked with shared libraries and calls callable shared object files:

3.2.1 Packaging Applications Using Callable File Formats

In many COBOL systems, subprograms and support modules must be linked to your programs by a linker utility after compilation. In Server Express, 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 Server Express you can run callable shared objects, .int files, and .gnt files without linking them into a system executable file. This ability is provided by the COBOL dynamic loader (see the the section Dynamic Loading for more details). Dynamic loading is used to:

To make use of the dynamic loader, you must compile your program to a callable shared object, intermediate code file, or generated code file; these file formats are known as the callable file formats. For example, the command:

cob -z myprog.cbl

creates the callable shared object myprog.so, while the command:

cob -u myprog.cbl

creates myprog.gnt

Callable shared objects, .int files, and .gnt files do not have to be linked into a system executable file to be able to run. However, they do need to be called by a system executable that has been linked with the COBOL run-time system. Server Express provides a default trigger program, cobrun (and for multi-threading applications, cobrun_t). The diagram below shows how an application could be packaged using the callable file formats and the cobrun trigger.



Figure 3-1: Trigger Executable

See the chapter Running for details on using cobrun and cobrun_t. See your Multi-threaded Programming book for details on multi-threaded programming.

You can create your own system executable file to trigger your application if required. See the chapter Linking to System Executables for details on creating system executable files.

3.2.2 COBOL Link Option

The UNIX system provides basic functionality to build and execute programs. Your COBOL system exploits this and provides additional COBOL-specific functionality. The Linker is used to create programs in an operating system executable format.

A linked program is a subprogram that is held in object form in a:

Any program, subprogram or support routine can be linked into these file types.

The procedural code of the linked file types is shared between multiple concurrent users. The procedural code of callable shared objects and shared libraries is also shared between multiple applications.

To run a COBOL application you must first invoke a standard UNIX system executable file. This is loaded by the system loader and control is passed to the main entry point. The application starts to run and control passes explicitly to called subprograms or implicitly to run-time support routines. See the chapter COBOL System Interface (cob) for details on how you specify the main entry point.

An executable file that requires the first entry point to be specified at run time is generally known as an executable run-time system (RTS) . The file $COBDIR/bin/rts32 (or $COBDIR/bin/rts32_t for multi-threaded applications) is the default executable RTS. An executable file that has the first entry point built-in at link time is generally known as an executable application.

To link the programs in your application use cob. The cob command can be used to link a program to the various system or language support routines, and, if necessary, to any called subroutines that are needed at run-time.

See the chapter Linking to System Executables for more details.

3.2.3 Dynamic Loading

UNIX normally requires the names of all called programs, and the called programs themselves, to be provided at link time. With Server Express, however, you can run programs without first linking them to system executables; these programs are dynamically loadable. The COBOL run-time system provides a dynamic loader that can load and execute dynamically loadable COBOL programs or subprograms.

The types of executable file that can be dynamically loaded are callable shared objects, .int files, .gnt files. Callable shared objects enable any type of program or subprogram (for example, COBOL, C or C++) to be dynamically loaded. For .int and .gnt files only COBOL programs or subprograms can be dynamically loaded. These files do not require linking to a system executable, although they do need a system executable as a trigger; Server Express provides the cobrun program (cobrun_t for multi-threaded applications), which you can use as a trigger (see the chapter Running for details).

Programs and submodules loaded using dynamic loading do not need to be linked to a system executable, which speeds the compile-to-run process, and gives increased run-time flexibility. For example, you can modify and recompile a dynamically loaded submodule without affecting any other part of the application, and without needing to relink a system executable.

The COBOL system enables each call to a program to be either linked directly to the program, if it is available at link time, or to be linked to the dynamic loader. At run time the dynamic loader searches for the named program and, if necessary, dynamically loads it.

The program name can be provided to the dynamic loader as either a literal or as the value of a data item. The dynamic loader searches for the named program in the following places:

  1. The list of linked programs, subprograms and routines in memory. The list also records the states of the programs, subprograms and routines. The states are:

  2. The file system for a dynamically loadable file for the program.

You can use flags to the cob command to explicitly name the programs that you want to be linked and directly referenced and those that you want to be dynamically loaded. Without explicit instructions, cob takes default actions that depend on how the COBOL source calls the program.

3.2.3.1 Default Behavior

The statement CALL data-name enables the name of the called subprogram to be specified dynamically at run time and implies dynamic loading. In a CALL statement, an ON EXCEPTION clause specifies the action to take if the subprogram cannot be loaded. Linked programs are not considered able to give an exception, unlike dynamically loaded programs and so the ON EXCEPTION clause implies dynamic loading.

Only the statement CALL literal with no ON EXCEPTION clause, when used in a linked program, does not imply dynamic loading. Instead, a direct reference is used; this is superior to dynamic loading in performance terms.

If a program is invoked in a way that implies dynamic loading, then it is invoked by the COBOL run-time system dynamic loader. The dynamic loader first searches the list of loaded programs, subprograms and support routines before trying to load the program dynamically from disk. If the program is already loaded, by virtue of being linked or previously dynamically loaded without any intervening CANCEL, then the dynamic loader simply passes control to it. If the program is not already loaded, then the dynamic loader searches for a suitable dynamically loadable file. The search order is affected by the environment variable COBPATH and the run-time tunable program_search_order . Callable shared objects are also affected by the LIBPATH, SHLIB_PATH or LD_LIBRARY_PATH environment variable. See the appendix Micro Focus Environment Variables, for details on environment variables, and the the chapter Run-time Configuration for details on run-time tunables.

3.2.3.2 Dynamically Loadable Files

There are three types of dynamically loadable program: callable shared object files, .int files, and .gnt files. If a program needs to be loaded, then the dynamic loader loads a callable shared object file in preference to a .gnt file, and a .gnt file in preference to an .int file, for any given program. Although you can reference the name, extension and path of a program file in a CALL statement, we recommend that you omit any path or extension and ensure that the basename of any dynamically loadable file corresponds to the program name.

3.2.3.3 Program Names and Entry Points

The COBOL system recognizes various forms of file for a program and assumes all files for a given program have filenames that share the same basename. This basename is taken to be the program name. The COBOL system uses the program name to identify a program and the dynamic loader also uses it to locate a program. Each program has a main entry point identified with the program name.

The main entry point into a program is the default point where execution of the program starts. This is the first non-declarative statement after the Procedure Division header. The COBOL language lets you to specify a program-name in the PROGRAM-ID paragraph. If specified, the program-name represents the name of the main entry point.

The ENTRY statement (see your Language Reference for details) allows additional entry points to be named which represent alternative places for the program to start.

The program is identified by the program name, but once a program is loaded, by linking or dynamic loading, the names of the entry points become available for use by the CALL statement. The CANCEL statement must only reference a program name and when executed causes the program to be unloaded, unless the program is linked into the system executable file. Also see the -l run-time switch in the chapter Descriptions of Run-time Switches.

We suggest that, for your convenience, if the PROGRAM-ID paragraph is specified, you make the program-name and the basename of a program source file the same.

Multiple programs can be combined to form a single callable shared object, system executable or shared library. Here the main entry point is the basename of the first program on the command line unless the cob -e flag is specified.

On file systems that support long filenames, filenames for programs that are to be dynamically loadable must be unique in the first 30 characters. This is because filenames longer than the entry point name limit are truncated to that limit when linked or dynamically loaded. Therefore, you are recommended to keep program source filenames below 30 characters long. See also the chapter System Limits and Programming Restrictions in your Programmer's Guide to Writing Programs.

3.2.3.4 Flexibility and Performance

Accessing a program via the dynamic loader is less efficient than accessing it directly via direct reference, even if the program has been linked into a system executable. If the program needs to be dynamically loaded the program needs to be read off disk. If the program is an .int file or .gnt file all subsequent calls in the program use the dynamic loader, so performance drops still further. However, the dynamic loader does give great build and run-time flexibility.

Dynamic loading of programs is especially suitable in a development environment. This is because it requires no link process, speeding the edit, compile and run cycle. It also gives more flexibility; you can even, while debugging, reload a changed version of a subprogram while the rest of the application remains running.

In environments where the application generally runs with a single user, you might need to use dynamically loaded .int files or .gnt files if the amount of memory available is limited. Dynamic loading provides you with full use of the memory management options provided by the Server Express dynamic loader, enabling you to control the amount of memory required by your application.

In environments where the application generally runs with multiple users, both memory efficiency and performance generally favor an application consisting of a system executable, linked shared libraries and/or callable shared objects. If the subprograms are very large or very numerous they can be combined into callable shared objects or, if size is more important than performance, packaged as .int files or .gnt files. See the chapter Writing Programs in your Programmer's Guide to Writing Programs for further details on performance.


Copyright © 2000 MERANT International Limited. All rights reserved.
This document and the proprietary marks and names used herein are protected by international law.

PreviousUsing Application Server Creating ProgramsNext"