COBOL Migration: What You Can Do Now

WRQ Sponsor Message

May 2002

COBOL Migration: What You Can Do Now

Even if you won’t be moving for years, prepare your COBOL today

By Wayne Boyer

The announcement from Hewlett Packard that it plans to discontinue manufacturing its HP 3000 product line in November 2003 has prompted a large amount of discussion regarding ways of converting applications to run on alternative platforms. This article will focus on COBOL-based applications that you expect to move over to some new system in the future.

Handling HP’s transition out of the 3000 community calls for solutions many organizations don’t have today. However, if your organization utilizes COBOL as a primary programming language and you expect to re-use this source code on another platform in the future, this article can help you. You can get started now on some of the steps that you will need to take, regardless of what platform you end up on in the future.

For current HP COBOL sites, there are at least four possible non-HP COBOL compiler vendors offering products that will run on non-HP 3000 hardware. These vendors are Acucorp, Fujitsu, LegacyJ and Microfocus.

If you study each of these vendors’ products, you will see differences between them — but fundamentally, they all are COBOL compilers that accept COBOL syntax. While Acucorp has gone to considerable effort to handle most of the non-standard HP-COBOL syntax, they have not yet managed to handle every such case. If you use one of the other three compilers, you will have slightly more work to do.

Most HP 3000-based COBOL source code contains some amount of code that is specific to either:

• The HP COBOL compiler syntax and operation

• The MPE/iX operating system

• Subroutine libraries

This article addresses the first category. Operating system and subroutine libraries of various types also need to be addressed. I hope to do so in a future article as more vendor solutions become available.

In addition, there can be variations in the level of standard COBOL being used. To ensure that we are thinking of the same thing, let’s further describe each of these situations and the different COBOL standard levels.

HP COBOL compiler syntax and operation

This is any character string that exists in any source code file that effects how the HP COBOL compilers operate. Further, this refers to any such character string that is not part of the internationally accepted standard for the COBOL language. There are two types of character strings that exist in HP COBOL that are not part of the standard language. These are compiler directives (lines beginning with a “$”) and HP-specific extensions to the regular COBOL language syntax.

Examples of these situations would be:

• $PAGE, an HP compiler directive that causes a form feed on the output listing;

• ACCEPT MY-DATA FREE ON INPUT ERROR …, an HP extension to the standard COBOL verb ACCEPT. Both ‘FREE’ and ‘ON ERROR’ are not standard COBOL;

• MOVE %33 TO MY-VALUE, an HP-specific octal constant which in this case corresponds to the ASCII Escape character (commonly used for printer control).

MPE/iX operating system

This is any character string that exists in any source code file that has no effect on the compiler but which does do something when the program is run. Examples would be:

• MOVE “!JOB J123,MANAGER.SYS “ TO OUT-REC. This is part of a MPE jobstream embedded within COBOL source code.

• MOVE “FILE MYFILE;DEV=LP” TO COMMAND-BUF. This is MPE/iX command syntax that is probably intended for use with the COMMAND intrinsic.

Subroutine libraries

This is any set of subroutines referenced in a COBOL program via the CALL statement.

CALL “DBGET” USING DB-NAME, …, A typical Image subroutine call

CALL “VSHOWFORM” USING COM-AREA, … A typical VPLUS subroutine call

Language Versions

All COBOL source code on an MPE/iX system can be categorized into one of four possible levels of COBOL based upon the COBOL language standards that have evolved over the years. Listed below are these four categories.

COBOL-68: This is the original COBOL produced for the HP 3000. Such source code may only be used on a classic architecture HP 3000 or in Compatibility Mode (“CM”) on a newer HP 3000 system. It is not difficult to upgrade old COBOL-68 source code to conform to a newer standard level.

COBOL-74: Many years ago, a COBOL-74 level compiler was released by Hewlett Packard. This was known as COBOL II. Currently, COBOL-74 source code can be either Compatibility Mode or Native Mode code. If you are still compiling source code as COBOL-74 code, look at what needs to be changed to treat all of your source code as COBOL-85 code.

COBOL-85: This is perhaps the most typical type of source code found on HP 3000 systems. COBOL-85 code can be compiled and linked into a Compatibility Mode PROG file or into a Native Mode NMPRG file.

COBOL-85 With 89 Addendum: Any source code compiled with the $CONTROL POST85 compiler directive must conform to the COBOL-85 standard and must also be compatible with the 1989 addendum to the COBOL language standard. All such source code must be compiled into Native Mode and is essentially the most up-to-date code from a language standards perspective. This is the situation that you will want all of your source code to be in before you start porting to a new platform.

What you can do

So now that we have talked about the situation, what can be done about it? If you determine that you are going to move your code somewhere, you can work on making your HP 3000-based source code as standard and as up-to-date as possible. Here is a list of tasks that will make your source code much more portable to any future COBOL environment.

Add the $CONTROL STDWARN compiler directive to your COBCNTL file. This will direct the HP COBOL compiler to produce messages identifying non-standard COBOL syntax. Some but not all of these syntax issues are discussed further on in this article. Note that you will get warning messages related to various obsoleted clauses in the IDENTIFICATION DIVISION. These are easy to delete or convert into comment lines. Be prepared for a surprise when you add STDWARN. There are a lot of non-standard extensions in use. Many of these are common to other compilers though, so you do not need to remove them from your code.

Review your COBCNTL compiler control file contents and ensure that you are using as few versions of this file as possible. Optimally, you should only have one version of COBCNTL in use so that all of your source code is compiled with a consistent set of directives. As you make progress on improving your source code for portability, you can add the DIFF74 directive if you are using older code and eventually add the POST85 directive to ensure that your code is compiled according to the most recent COBOL language standard.

Note that with the DIFF74 directive, you will probably get warning messages related to various obsolete clauses in the IDENTIFICATION DIVISION. These are easy to delete or convert into comment lines. An easy way to do this is with a MPEX global change on all of your source code. If you have never done this before, you can redirect the compiler to use a special COBCNTL file by issuing a :FILE command before the compile: FILE COBCNTL.PUB.SYS = yourcobcntlfilename

Develop a means of converting QEDIT type files or other filetypes into regular fixed ASCII EDTCT type files. When you eventually port your code over to another platform, QEDIT probably isn’t going to be there and you will need to have a consistent, standard file type for your source code.

Compiler directives

Eliminate as many embedded compiler directives as possible. This may be the hardest part of porting your COBOL source code to a new platform. Some compiler directives follow which are easy to eliminate.

$COMMENT – This is a directive that is just a comment line. Convert all of these directives to regular COBOL comment lines (a “*” character in column 7).

$CONTROL QUOTE – This directive is something of a holdover from COBOL-68. Originally character strings could be delimited by single quote marks. This directive lets you perpetuate that method. You should change your single quote marks to double quote marks and remove this directive from your source code or COBCNTL if you have it there.

$CONTROL LIST and NOLIST – These directives control what source code is shown on a compile listing. Removing these directives will cause no harm other than probably an increased use of paper.

$PAGE and $TITLE – These directives effect only your compile listings and could easily be converted into normal standard COBOL comment lines.

$EDIT – This directive is probably not used in many organizations but it could be complex to eliminate. The logical alternatives would be COPY statements using the COPYLIB or $INCLUDE compiler directives. It is safe to assume that all alternative compilers will support something similar to $INCLUDE.

$DEFINE – This directive is used to define macros. In most cases removing macro definitions and their corresponding references in the source code is a complex task. I would recommend deferring this work until more is known about the future platform for your code.

Other steps

Isolate as many HP COBOL language extensions into the COPYLIB or into $INCLUDE files as possible. This will allow you to use one set of source code containing an HP language extension. Once you are ready to port to a different platform, you can change this one common shared piece of code instead of changing dozens of occurrences of the extension in multiple source code files.

Eliminate the usage of certain HP COBOL language extensions related to file locking: COBOLLOCK and COBOLUNLOCK, EXCLUSIVE and UN-EXCLUSIVE

While Acucorp’s AcuCOBOL product supports quite a few HP language extensions, AcuCOBOL does not support the above extensions, and Acucorp is not intending to add support for these constructs in the future. Convert your source code to use the FLOCK and FUNLOCK intrinsics instead of these language extensions. You can also write little subroutines to hide these intrinsics so that eliminating these language extensions doesn’t result in more usage of MPE/iX-specific subroutines.

Locate and eliminate all of these unusual HP COBOL language extensions. These extensions are essentially undocumented and are simply identified by their reserved word. Where possible, page references to HP’s COBOL II/XL Reference Manual are given. If these extensions exist in source code processed by AcuCOBOL or any other compiler, compilation will fail.

Reserved Word - Page Reference

DIVIDE-BY-ZERO No information available

BEGINNING 9-136

COMMON 5-4

DISABLE E-10

ENABLE E-10

ENDING No information available

FILE-LIMITS No information available

MORE-LABELS 9-138

PROCESSING No information available

If you use RLs and/or XLs, prepare an automated method (perhaps a jobstream) of recreating each of your RL or XLs from only the source code. The library itself isn’t going to get ported anywhere but your source code is. Having the ability to recreate each library ensures that you know exactly which source code files need to be compiled in order to create a library on your future target platform.

Eliminate any usage of subroutine switch stubs. These are used to handle switching between native mode and compatibility mode when a calling program and a called subroutine are not of the same mode.

Work toward having all code utilize 32-bit words instead of 16-bit words for binary data. Subroutine parameters need to align with the native word size This involves using the CALLALIGNED, LINKALIGNED and INDEX32 directives for 32-bit words. The 16-bit directives that you will want to phase out are CALLALIGNED16, LINKALIGNED16 and INDEX16.

Remember that in the future, you will probably be operating on a platform that is a 64 bit machine. The best that you can probably do now is to completely convert from 16 bit parameters to 32 bit. In general, this means changing the definition of some variables from ‘PIC S9(04) COMP’ to ‘PIC S9(09) COMP’.

Avoid using the MPE/iX variable COBRUNTIME. This variable allows you to control how error or trap handling is managed. The chances of this existing on a different platform are small.

Re-name any variable or paragraph names that will conflict with the additional reserved words that are being added to COBOL with the pending 2002 COBOL standard. Also re-name any variable names or paragraph names that conflict with the vendor-specific reserved words in your future COBOL compiler.

More detailed information is in HP’s reference manuals for COBOL, available at www.docs.hp.com. You can also order the COBOL Reference Manual Supplement and the old COBOL II/V manual.

Depending upon the state of your source code and your knowledge of your future environment, the information in this article can help you to eliminate a few months of delays in the process of porting your applications to a new environment. While the entire migration process will be difficult and time-consuming for many organizations, at least with a standard language like COBOL, migration is quite feasible.

Wayne Boyer (callogic@aol.com) has worked with HP 3000s for 24 years and is the president of Cal-Logic, a consulting organization specializing in business applications running on Hewlett Packard systems.