Chapter 2: Portability Issues

This chapter describes syntax that the NetExpress Compiler can flag, using warning or information error messages, as being incompatible between NetExpress and COBOL for UNIX. However, the NetExpress Compiler cannot flag all incompatibilities, so this chapter also describes syntax that you should manually check and change before porting the program to a UNIX system.

If a section is flagged as Not Server Express, the portability issues in that section can be ignored if you are publishing to a UNIX system that has Server Express installed.

2.1 Syntax Checking

The default for the INTLEVEL directive, for both NetExpress and COBOL for UNIX, is set to 2. This is the value required to create portable intermediate code. However, certain syntax in NetExpress COBOL, even when compiled with INTLEVEL"2", generates intermediate code that might not run on UNIX systems.

Therefore, if you set the WARNINGS"2" Compiler directive, the NetExpress Compiler flags those syntax structures likely to cause problems if ported to a UNIX system.

2.2 Syntax Flagged

Not ServerExpress:
If you compile a program with the INTLEVEL"2" and WARNINGS"2" directives set on NetExpress, various syntax structures are flagged. The flags are in the form of information or warning messages. You can increase the severity of an informational or warning message to a severe error using the CHANGE-MESSAGE Compiler directive. The following syntax is flagged:

Literals greater than 160 bytes. The COBOL for UNIX limit is currently 160 bytes.
Call conventions. The NetExpress Compiler accepts call conventions not acceptable to the COBOL for UNIX Compiler; for example, both call conventions 256 and 512 are acceptable to NetExpress, but not to COBOL for UNIX.
Filenames that contain spaces.
Entry points that each have a different call-convention specified. COBOL for UNIX assumes that the first entry point sets the call convention for the remaining entry points.
By value items greater than 4 bytes. In COBOL for UNIX, a maximum of 4 bytes can be passed by value in a CALL statement. If you try to pass a larger value it is possible that the operating system will fail.
The IS EXTERNAL DEFINITION and IS EXTERNAL REDEFINITION phrases. These are only available on NetExpress.
The number of parameters on an entry point if it exceeds 255 (the maximum for COBOL for UNIX).
Multi-threading syntax. This is not available in COBOL for UNIX.
Any Object COBOL support detected in a source program. Object COBOL is only supported in Object COBOL Version 4.1 for UNIX and later versions.

2.3 Syntax Not Flagged

The following syntax is not flagged, but you should check for occurrences in your programs:

Library routines that do not work on UNIX (that is, those marked in your COBOL for UNIX documentation as DOS, OS/2 or Windows only, or those that are specific to the PC.). For example, the PC_ library routines, such as PC_FIND_DRIVES, are not available in COBOL for UNIX. Some call-by-number library routines are different between NetExpress and COBOL for UNIX. For example, controlling mouse-function using the x"AF" routine is not available in UNIX.
Calls to Panels2. These are not supported.
Explicit calls to .dll files.
Filenames that do not work on UNIX; for example, those that have a .dat extension, or that contain spaces, or drive identifiers.
Embedded PC characters (that is, non-printing characters) in literals.
COMP-5 data items in the File Description. If you specify COMP-5 data items in the file record descriptions you should note that the byte-order might be different between PC and UNIX systems.
If the program contains Object Oriented syntax, then for COBOL for UNIX you should ensure that the MFOO directive is set, preferably using a $SET statement at the beginning of the source code. See the next section for details.

You should also be aware of the following differences between COBOL for UNIX and NetExpress COBOL:

Byte ordering. If your applications pass parameters between programs you need to be aware of the way in which systems pass parameters. Some UNIX systems have COBOL byte ordering, rather than the reverse byte ordering used by PCs. Therefore, a program that has been tested and works on a PC with an Intel chip might not work as expected when moved to, for example, a SPARC system. This issue only arises when passing parameters between COBOL and non-COBOL programs, or where the programs originating and receiving data are running on different machines.
The default filetypes differ between PCs and UNIX.
The delimiter used for line sequential files differs between PCs and UNIX.

2.4 Using the LINKCOUNT Directive

Not ServerExpress:
The COBOL for UNIX Compiler has a different mechanism to the NetExpress Compiler for allocating storage slots for data items. Therefore, programs that work when compiled using NetExpress might give the Compiler error:

0067 Please recompile using a larger value for the LINKCOUNT directive

when published to the UNIX system. If this happens you should set the LINKCOUNT directive in the program causing the error using a $SET statement in the COBOL source program.

2.5 Debugging and .idy Files

The format of .idy files is different between the NetExpress and COBOL for UNIX products. Hence, the .idy file created by NetExpress compilation cannot be used by COBOL for UNIX.

2.6 Object Oriented Programs

Not Server Express:
In Object COBOL V4.1 for UNIX you need to specify the MFOO Compiler directive to check Class and OO programs. This directive loads the Object COBOL reserved words. NetExpress accepts the MFOO directive, but ignores it, as all the Object COBOL reserved words are already loaded by default.

To develop an OO program or class under NetExpress, and then recompile it using COBOL for UNIX, you need to specify the MFOO directive. This is best done by setting the directive using a $SET statement in the source code.

You should also be aware of the following:

If any user classes inherit from a Class library a class with data, compilation of these user classes might fail on UNIX since the class library is different to the Class library on NetExpress. You are advised to inherit a class without data.
The semantics of the Class-Control section was changed for NetExpress. This might cause problems when recompiling with COBOL for UNIX. Class-Control entries have the following form:
class-control. logicalClassName is class "physicalFileName".

In NetExpress, the logicalClassName is scoped within the individual class or program in which it exists. It has no effect beyond this. In earlier versions of Object COBOL, the logicalClassName has global scope; if entries exist for a given logicalClassName in more than one compilation unit, the entries need to match, otherwise run-time error 119 occurs.
On COBOL for UNIX, a class can have a Procedure Division outside of a method which is executed once when the class is loaded. This structure has been removed in NetExpress and replaced by the Initializeclass Class method. This method is invoked by the Object COBOL run-time system when the Class is first loaded (it thus has a similar effect to the use of a Procedure Division in COBOL for UNIX). Initializeclass methods are therefore not automatically executed in Object COBOL V4.1 for UNIX.

2.7 CGI Applications

The various versions of COBOL for UNIX provide differing levels of support for the syntax and run-time support required by CGI applications. For example, Object COBOL V4.1 for UNIX introduced the ACCCGI run-time support module.

The UNIX Option provides a standard level of CGI syntax and run-time support for all COBOL for UNIX products. If the COBOL for UNIX product provides its own syntax or run-time support, this is automatically used by the UNIX Option.

Introduction

Publisher Set-up