Building Applications Using Micro Focus COBOL

Building Applications Using Micro Focus COBOL

Abstract If you look through the Micro Focus COBOL documentation, you will see many different executable file types referenced: int, gnt, exe, dll and others. If you have questions about the differences between these formats and why they exist, this paper aims to provide answers. It covers the historical and technical reasons behind the different formats and provides guidance on which to use

Contents Introduction... 1 Intermediate Code... 1 What is the COBOL Run-Time System?... 2-3 The Introduction of Generated Code... 4 Packaging Applications... 5 Effective Use of Memory... 5 Support for OS/2 and the Introduction of Linked Applications... 5 The Use of Operating System Application Programming Interfaces... 6-7 Which Executable Format Should I Use?... 8 Portability versus Performance... 8 Which Type of Generated Code Should I Use?... 9 Mixing Formats... 9 Which COBOL Run-Time System Should I Use?... 10 Shared versus Static Linked Run-Time Systems... 10-11 Single versus Multi-Threaded Run-Time System... 12 Conclusion... 13 0

Introduction If you have been developing Windows or UNIX applications using Micro Focus COBOL, you will have encountered the many different file types used for different executable file formats. These include.int,.gnt,.exe,.dll,.lbr and others. However, unless you have been using Micro Focus COBOL for a long time, you may wonder what these different formats are and when best to use the different types. This paper examines the technical and historical reasons for each of these formats, and also takes a look at the different COBOL Run-Time Systems. Hopefully, by the end of this paper, you will have a better understanding of the different executable formats and Run-Time Systems and be able to determine the best choice for use in your application. Note that many of the reasons for the different executable formats are as much historical as they are technical, so this paper may read like a history lesson as much as a technical paper. Intermediate Code Micro Focus COBOL first appeared on 8-bit microprocessors with the release of Micro Focus CIS COBOL more than 20 years ago. There were two primary goals that influenced the choice of executable format: The size of the executable. The maximum amount of memory that could be installed on an 8-bit machine was 64K. At that time, 32K was considered a large amount of memory. So, the executable files had to be very compact to make the best use of the limited amount of available memory. Portability. It was intended that Micro Focus COBOL should be available on many different processors and operating systems. Therefore, it was desirable to have an executable format that would only require source code to be compiled once, but the resulting executable files would run on all of the platforms supported by Micro Focus COBOL. Intermediate (int) code was introduced to meet the challenge of these two goals. Intermediate code can be considered to be a high-level machine code for a microprocessor that is ideally suited for executing COBOL. In other words, it is an abstract machine code. To run intermediate code, an interpreter is needed. This is built into the COBOL Run-Time System. One way of looking at intermediate code is as a series of subroutine calls. The interpreter contains subroutines that handle each int code instruction. As each instruction is read from the int code file, a call is made to the particular routine in the interpreter that handles that instruction. Once the instruction has been executed, the interpreter goes back to the int code to get the next instruction. Because the abstract machine was designed to be tuned specifically for COBOL applications, the instructions are very compact. For example, one small instruction can add together two COBOL variables, regardless of the different type of COBOL data types used (for example, binary, packed decimal, display). Native machine code to perform such an action would be considerably larger. 1

Once a program has been compiled to intermediate code, all that is needed to execute it is a COBOL run-time system. Therefore, once the Run-Time System has been ported to a new platform, the application is able to run on that platform without having to be recompiled. This was exceedingly useful in the early days of Micro Focus since all of the Micro Focus tools, including the compiler, and Animator, were written in COBOL. Because they were compiled to int code just like any other application, it meant that they could be easily ported to a new platform. Even today, the compiler and large portions of the COBOL system are still written in COBOL. What is the COBOL Run-Time System? In order to execute a program developed using Micro Focus COBOL, you need a run-time system. The Run-Time System can be a separate executable or linked in to the application (as we will see later). Figure 1 shows the main components of the COBOL Run-Time System. Program Loader Int Code Interpreter Control Routines Program Callable Routines Operating System Support Package Figure 1 The COBOL Run-Time System 2

The five main parts of the Run-Time System are: The Program Loader. This loads COBOL programs into memory as needed. The Int Code Interpreter. This takes control if an intermediate code program is loaded. It interprets each intermediate code instruction and performs the actions required. The Control Routines. These are used by both the Int Code Interpreter and generated code (see the next section) to perform operations such as basic file handling, input from the keyboard and output to the screen, memory management and complex string/numeric-edited field handling. The Program Callable Routines. These are the call-by-number and call-by-name routines that are available to your program. They provide additional functionality not available in the COBOL language. The Operating System Support Package. This provides the interface to the underlying operating system. When the COBOL Run-Time System is ported to a new platform, it is usually only the Operating System Support Package that needs to be changed. In addition to the core Run-Time System, there are additional modules that are required to provide more complex functionality. These include: The Accept/Display Module (ADIS). This provides all of the functionality to handle enhanced and full screen accept and display statements. The File Handler (EXTFH). This provides all of the support for handling indexed sequential files. Other modules that handle external data, communications, etc. These modules are loaded by the Run-Time System as needed by an application. 3

The Introduction of Generated Code Because intermediate code is interpreted, the performance of applications that are executing a lot of computing intensive operations can be relatively slow. Therefore, as 16-bit processors were introduced and more memory was available (up to 640K), Micro Focus produced Level II COBOL which introduced the concept of generated native code (gnt). Generated code (gnt) files contain native machine code specific to the processor you are using, rather than intermediate code. In addition, the compilers perform optimization on the generated code in order to execute the code as fast as possible on the target processor. This means that the performance of the application is significantly faster for computational-bound applications since the Run-Time System does not need to interpret instructions when the application is executed. All of the conversion to native code is done when the application is compiled. Note that even today, the compilation process is a two-stage process. 1. The first stage takes the COBOL source code and produces an intermediate code file (int). 2. The second stage takes the int code file and generates the corresponding native code. The names given to the tools that produce these different files has changed over the years. Today, the first stage is called the Checker and the second stage is called the Compiler. If you have been using Micro Focus COBOL for many years, you may be familiar with the term Generator to refer to the second stage of the compiler, hence the term Generated Code. To be consistent with the terminology used today, we will use the term Compiler for the rest of this paper. Even though gnt code files contain native code, they still require a COBOL Run-Time System to load and execute them. Although the Interpreter is not needed for gnt code, as seen in the previous section, the COBOL Run-Time System provides the infrastructure needed for execution of the program. 4

Packaging Applications While breaking applications in to multiple modules provides for efficient memory management, as well as enabling teams of programmers to work on the same application effectively, it often results in a single application consisting of large numbers of int and gnt files. This makes managing the distribution of applications more difficult than applications linked into one executable. To overcome this problem, Micro Focus introduced the concept of Library (lbr) files. A tool called the Library Manager was provided that enabled programmers to package multiple gnt and int files into a single lbr file. This meant that instead of distributing multiple int and gnt files, the programmer only had to ship a single lbr file (or more if they wanted) and the COBOL Run-Time System. Effective Use of Memory Even though the 16-bit systems supported more memory, customers were trying to move larger and more complex COBOL applications down to the PC. To handle these systems, Micro Focus COBOL supported the idea of memory overcommit. If a program was larger than would normally be possible in the amount of memory available, the programmer could split it into sub-programs that the COBOL Run-Time System could load into memory as needed. If the program needed to load a module and there was insufficient memory, the COBOL Run-Time System would swap modules that had not been used for a while from memory to disk in order to make room for the new module. In this way, Micro Focus COBOL could handle applications that were larger than the available amount of memory. Similarly, if a program used the COBOL segmentation feature, the COBOL Run-Time System would dynamically load the different segments in to memory as required. Today, this type of memory management is handled by the operating system, but in the days before Windows and OS/2, MS-DOS did not provide anything like this, so the Micro Focus COBOL Run-Time System memory management was very advanced compared with other languages on the market. Support for OS/2 and the Introduction of Linked Applications When IBM OS/2 was introduced in the late 1980s, it was the first PC-based operating system that provided good memory management facilities. Micro Focus was one of the first companies to introduce support for OS/2 with the release of COBOL/2 (COBOL/2 also ran on MS/PC-DOS). With COBOL/2, Micro Focus introduced its users to the concept of compiling programs to object (obj) code and then linking them using a Linker utility with the required Run-Time System modules to provide standalone executable (exe) files. While programmers using other languages had done this for some time, until OS/2 (and later, Windows 3.0) came along, the operating system did not provide the memory management capabilities needed for large applications, meaning that linked applications could only use the amount of memory available on the machine. With the introduction of OS/2, the operating system finally provided the necessary level of memory management and therefore Micro Focus was able to support linking of applications. 5

OS/2 also introduced the concept of dynamic link libraries (dlls). A dynamic link library is a linked executable file that can be dynamically loaded by a program as needed. Prior to the introduction of dlls, if you were linking applications, all of the code required for a program had to be linked into one executable file. Dlls finally provided to programmers in other languages the benefits that Micro Focus COBOL users had enjoyed for many years with int and gnt code. So, why was the introduction of linked executables important for COBOL users? The use of int and gnt code worked great if you only developed in COBOL and the COBOL Run- Time System s routines provided all of the additional support you needed. However, if you wanted to develop in multiple programming languages or you wanted to call operating systems routines that were not accessible using COBOL Run-Time System routines, compiling to int and gnt code was not as convenient as will be seen in the following section. The Use of Operating System Application Programming Interfaces Prior to Windows and OS/2, the mainstream operating system for the PC was MS-DOS (PC-DOS on IBM Personal Computers). The only interface provided by MS-DOS to access operating system functions was a low-level machine code interface. In addition, the operating system only provided a basic set of functionality, such as file management, memory management and basic input from the keyboard and output to the screen that provided functionality not much better than old teletypes. To provide better screen and keyboard access, programs had to bypass MS-DOS and access the computer s video memory and Basic Input/Output System (BIOS) functions directly. Again, this required the programmer to write low-level machine code. To remove the need for this, the different compiler vendors provided run time routines, callable from the high-level programming language that provided access to the low-level features of the operating system and computer. Micro Focus was no exception and provided an extensive set of COBOL run time routines to read from and write to video memory, read the keyboard directly, provide access to the file system and so on. Windows and OS/2 introduced PC programmers to the concept of Application Programming Interface (API) functions. These are functions provided by the operating system to enable a program written in a high-level language to directly access the features of the operating system. In addition, the operating system now provided a wider range of functionality, including the capability to write programs with graphical user interfaces. Unfortunately, the APIs provided by the operating system were not directly callable from COBOL since they required language features such as pointers to data and procedures, different calling conventions, passing parameters by value and so on. These features are common in languages such as C, but were not provided in standard COBOL. However, the number of functions provided by the operating system made it impractical for Micro Focus to provide access to all of this functionality via COBOL Run-Time System routines. To provide access to the rich set of API functions to COBOL programmers, Micro Focus added features to the COBOL language in the late 1980s that enabled a COBOL program to directly call API functions. 6

However, although the language had been extended, the use of int and gnt code still posed a problem when accessing API functions. All of the API functions are provided in dynamic link libraries. In order to access the API function, you needed to link your application with an import library for the dynamic link library that contained that API function. An import library contains code that locates each function at run time and makes it accessible to your application. Because int and gnt code modules are not linked, there was no means for the program to locate the required API function. Although Micro Focus provided alternative mechanisms for accessing the API functions from int and gnt code, the most effective way to access them was to compile your program to an obj file and link it with the COBOL Run-Time System and the relevant import libraries. You will also find linked executables easier to use if you are developing applications using different programming languages. 7

Which Executable Format Should I Use? Given all of the different executable formats that you can create using Micro Focus COBOL, it can sometimes be difficult to decide which one to use. This section provides some guidelines but, obviously, the choice will ultimately depend on your individual requirements. Portability versus Performance For a particular level of COBOL, Micro Focus COBOL source code is portable across all platforms supported by that level of COBOL (assuming, of course, that you do not make calls to API functions specific to a particular operating system). The source code must be compiled on each platform, using the Micro Focus COBOL compiler for that platform. However, the intermediate code is also portable across platforms for the same level of Micro Focus COBOL. This means that as long as you have a COBOL Run-Time System for each of the systems on which you wish to execute your application, you can compile your program on one system and simply deploy the int code to each of the target platforms. So, for instance, you could develop your application on Windows and then execute the int code modules you have created on Sun Solaris, HP/UX, Linux and many other UNIX platforms. If this notion of portability of code seems familiar, it may be because Java has gained so much attention because of its support for write once, run anywhere. This concept is not new Micro Focus has been enabling programmers to do this with COBOL applications for over 20 years! The power of this becomes apparent if you use Micro Focus Net Express and Micro Focus Object COBOL Developer Suite or Micro Focus Server Express together to develop applications. You can develop your applications on Windows using the powerful graphical tools provided with Net Express and then easily publish your applications to your chosen UNIX platform with the click of a button. The application will then be run on UNIX using the appropriate UNIX Run-Time System. Note that later versions of Micro Focus COBOL are backwards compatible with int code created using earlier versions of Micro Focus products. So, for example, int code created using Micro Focus Object COBOL on UNIX can be executed using Net Express on Windows NT or Server Express on UNIX. The reverse situation is not necessarily true. Because later products have extended the abstract machine to support new technologies, you may need to use compiler directives to notify the checker that it should produce int code that can be executed on older products. The downside of using int code is performance. Because it is interpreted, the performance will not be as good as running generated code. The level of performance difference varies, depending on the functionality of your application. If you application is very I/O bound, in other words, it spends a lot of time reading/writing files or waiting for user input, then the performance difference between intermediate and generated code is unlikely to have much impact on the performance of your application. However, if your application performs a lot of calculations and other compute-intensive operations, then the difference between the performance of intermediate code and generated code can be very significant, as much as 2 orders of magnitude. 8

If your application is going to be deployed on multiple platforms and does not use operating-system specific features, then the use of intermediate code is worth considering. Only you can determine if the performance of intermediate code is good enough for your needs. There was one other reason for choosing intermediate code in the past. Until recently, the Micro Focus Animator debugger could only be used to debug int code. It could not be used on generated code. For this reason, some customers felt more comfortable shipping the code they could debug. However, with the release of Net Express on Windows and Server Express on UNIX, these products can now debug native code as well as int code. It is interesting to note that Micro Focus Animator was one of the first Visual debugging tools for any programming language that enabled programmers to see their code as it was being executed and provided the ability to change the contents of variables and reset execution to any point in the application. COBOL programmers were able to do tasks with Animator that programmers in other languages wouldn t be able to do for many more years. Which Type of Generated Code Should I Use? If you are only going to ship your application on one platform or if performance is critical to you, then you should consider generated code. Next the decision is whether to create gnt modules or linked executables. As previously mentioned, on 16-bit platforms there were good reasons to use gnt code for better memory management. If you have been using Micro Focus COBOL for many years and are already creating gnt code then, by all means continue to use it. This is especially true if you do not need to access operating system APIs or functions written in other languages. If you are just moving to Micro Focus COBOL or have an application that makes extensive use of operating system APIs or functions in other languages, then you should consider linking your application into an exe file and linking sub-programs into dynamic link libraries. Mixing Formats It is important to note that you do not need to necessarily choose just one format. If you choose the shared Run-Time System or the full static-linked Run-Time System (see the next section), you can make calls to gnt or int code modules from a linked executable. 9

Which COBOL Run-Time System Should I Use? Once you have decided on an executable format, the next decision is which COBOL Run- Time System you should use. There are two main types: single-threaded and multithreaded. In addition, if you decide to link your application to form executables and dynamic link libraries, you must choose between the static-linked or shared Run-Time Systems. This section examines these choices. Shared versus Static Linked Run-Time Systems In most cases, if you are linking your application, you will want to choose the shared Run-Time System. In this case, all you are linking into your application is a small piece of code that loads the main Run-Time System into memory and provides access into it for all of the various Run-Time System routines used by the program. The actual Run-Time System is provided as one or more dynamic link libraries that can either be shipped with your application or provided as a separate installable package (this is called the Micro Focus Application Server). If you static-link your application, all of the Run-Time System functionality needed for your application is linked into your application exe or dll file. You can choose the level of run time functionality to be linked into your application from the following options: Lite. This provides a sufficient level of functionality needed for most applications consisting of obj files linked into an executable file. It does not provide support for: calling int or gnt code modules or the packaging of files into lbr files; shared memory allocation; run time configuration using COBCONFIG or DD_ filename mapping 1. Base. This is the default option. It provides all of the functionality needed for linked COBOL applications except for the capability to call int or gnt code modules. Full. This provides all Run-Time System support, including the ability to call int or gnt code modules. 1 For more information on these features, refer to the Net Express documentation. 1 0

So which Run-Time System should you choose? For most applications, you should choose the shared Run-Time System. This provides the following benefits: Multiple COBOL applications on the same machine can use the same Run-Time System. The overall size of the executables is reduced since the run time support needed for each executable does not need to be linked into each one. Updates and bug-fixes to Run-Time System modules can easily be applied without needed to re-link your applications. The static-linked Run-Time System would be chosen if you have developed a small standalone application that you want to supply as just one executable. 1 1

Single versus Multi-Threaded Run-Time System For most COBOL applications, the single threaded Run-Time System will be the one you will choose (this is the default). The multi-threaded Run-Time System was introduced in Visual Object COBOL, released in 1996. Visual Object COBOL introduced much of the core technology that later became Net Express. Micro Focus was the first COBOL vendor to introduce the concept of multi-threading to COBOL programmers. The multi-threaded Run-Time System will normally only be used in one of the following cases: You specifically develop a multi-threaded application using Micro Focus COBOL extensions to support multi-threading. You are developing a mixed Java/COBOL application where Java may call COBOL or COBOL may call Java. 2 You are developing COM components in COBOL that are required to be thread-safe. 3 2 See previous white paper, From COBOL to Enterprise Java Beans with Net Express for more information. 3 See previous white paper, Developing Mixed Visual Basic/COBOL Applications for more information. 1 2

Conclusion As computer technology has evolved, Micro Focus COBOL has evolved along with it. Starting with 8-bit systems, then 16 and 32-bit systems, and now the availability of 64-bit systems, Micro Focus has continued to be available on the new platform, enabling its customers to keep up with the changing face of technology. About the author: Wayne Rippin is a self-employed consultant. Previously, he worked for Micro Focus for 16 years, first as a systems programmer and later as a product manager. His most recent role there was director of product management, leading a team of product managers responsible for Net Express, Mainframe Express and Unix compiler products. 1 3

Micro Focus Choosing the right partner is as critical as choosing the right technology. As you move forward to meet these demands and the demands of your customers, Micro Focus continues to move forward with you as your strategic ally for legacy change. Unlike other e-business vendors, our approach starts with your enterprise legacy system and is designed to leverage, integrate and build upon your legacy assets. We have no computers or applications to sell. Our focus is to build the best tools to make your legacy system better. For more information on this approach or any of the supporting Micro Focus technologies, please contact your Micro Focus representative, or use the contact information listed. 2002 Micro Focus. All Rights Reserved. Micro Focus, Animator and Net Express are registered trademarks, and Object COBOL and Server Express are trademarks of Micro Focus. Other trademarks are the property of their respective owners. 1 4