| Creating 64-bit Programs | Internationalization Support | |
This chapter provides guidelines on developing applications that are portable at either source code or intermediate code level between Server Express and equivalent systems on other environments. These systems are principally Net Express, Mainframe Express and Object COBOL Development Suite. For brevity, this chapter uses "Windows" to refer to Windows 95, Windows 98 and Windows NT.
This chapter assumes a working knowledge of the Windows and UNIX operating systems and of the COBOL development systems provided for these operating systems.
This COBOL system offers the ability to execute applications by having an interpreter (in the run-time system) execute the intermediate code. Under certain circumstances the intermediate code can be executed on a different machine and operating system from that on which it was created.
The ability to migrate intermediate code enables Value Added Resellers (VARs) and Independent Software Vendors (ISVs) to address the needs of vertical markets and to help provide open system solutions.
Generated code , being native machine code, usually gives a gain in performance of an order of magnitude over intermediate code. If you require performance rather than portability you should use generated code. Intermediate code is preferable if your main interest is in portability and ease of distribution. If appropriate to your business, this or an equivalent COBOL system can optimize the intermediate code into generated code for the machine and operating system in use.
Portability is achieved using the INTLEVEL Compiler directive. The guidelines in this section describe programming methods that enable you to make best use of this directive in creating portable applications.
The directive has the format:
[NO]INTLEVEL"integer"
where integer can take a value of 2, 4 or 5. For detailed
information on the INTLEVEL directive, see the chapter
Directives
for Compiler in your Server Express User's Guide.
The following sections describe how to use the INTLEVEL Compiler directive to develop portable applications.
To create portable intermediate code, set INTLEVEL to 2 or 4.
INTLEVEL"2" provides portability from older versions of Micro Focus COBOL:
INTLEVEL"4" provides portability between Net Express and Server Express. In particular, INTLEVEL"4" provides:
By specifying the INTLEVEL"2" Compiler directive, you can ensure that any intermediate code created on any environment (using any of the COBOL language as defined in your Language Reference) is portable to any other environment that supports INTLEVEL"2".
In addition to this syntax, there are the CBL_ library routines . These provide generic system-level extensions to the COBOL language.
By observing the portability guidelines and known restrictions listed later in this chapter, you can ensure that the resulting intermediate code executes with the same results on the Net Express and Mainframe Express, and Server Express.
The intermediate code can be subsequently translated into native code by the equivalent Micro Focus COBOL system for execution in the required environment.
When developing portable applications you should be very careful not to make them environment-specific - for example, by hard-coding a filename. In many situations, you can use the CBL_ library routines to help you avoid environment-specific code. In general, code developed on Server Express is portable to Net Express and Mainframe Express, and vice versa, although you should see the section Restrictions later in this chapter for more information.
You do not need the dialect-controlling directives to ensure portable intermediate code, and specifying them does not guarantee that non-portable syntax is flagged when the program is syntax-checked.
Of the call-by-name library routines, only those whose names begin with CBL_ are portable. The call-by-number routines are not portable.
If you are porting Server Express source code to Object COBOL Development Suite V4.1 or earlier (abbreviated in the following sections as OCDS) you can use the INTLEVEL and WARNINGS directives to flag code that is incompatible between Server Express and OCDS However, the the Compiler cannot flag all incompatibilities, so this chapter also describes syntax that you should manually check and change before porting the program to OCDS.
If you set INTLEVEL"2", you can create intermediate code that is portable between Server Express and OCDS. However, certain syntax in Server Express, even when compiled with INTLEVEL"2", generates intermediate code that might not run on OCDS. Therefore, if you set the WARNINGS"2" Compiler directive, the Server Express Compiler flags those syntax structures likely to cause problems if ported to an OCDS system.
If you compile a program with the INTLEVEL"2" and WARNINGS"2"
directives set on Server Express, 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:
The following syntax is not flagged, but you should check for occurrences in your programs
In OCDS you need to specify the MFOO Compiler directive to check Class and OO programs. This directive loads the Object COBOL reserved words. Server Express 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 Server Express, 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:
class-control. logicalClassName is class "physicalFileName".
In Server Express, 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.
The OCDS Compiler has a different mechanism to the Server Express
Compiler for allocating storage slots for data items. Therefore, programs
that work when compiled using Server Express might give the Compiler
error:
0067 Please recompile using a larger value for the LINKCOUNT directive
when published to an OCDS 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.
The format of .idy files is different between the Server Express and OCDS products. Hence, the .idy file created by a Server Express compilation cannot be used by OCDS.
There are a number of other directives that can affect the intermediate code created. When portable intermediate code is required, you should use the default settings of these directives. The list below shows the directives that, if available on your COBOL system, can cause problems if changed:
REENTRANT
P64
DIALECT"ISO2000"
The following sections provide additional guidance on developing applications that are portable between the Net Express, Mainframe Express and Server Express environments.
Try to avoid using any features specific to your operating system. If you must use them, your application can find out which operating system it is running on by using the COBOL system library routine CBL_GET_OS_INFO.
A major area of incompatibility between Server Express, and Net Express and Mainframe Express is the definition of the user attribute byte. It is best to avoid using this; instead, to select video attributes, use the language extensions in the portable syntax subset defined in the section Portable Syntax. The video attributes that can be displayed depend upon the hardware on which the program is running. The following attributes can be specified in several ways using COBOL syntax:
| BACKGROUND-COLOR BLINK FOREGROUND-COLOR HIGHLIGHT LOWLIGHT |
NO-ECHO REVERSE-VIDEO SECURE UNDERLINE |
Screen I/O for programs executed using the CBL_EXEC_RUN_UNIT routine is not portable between Windows environments and UNIX environments.
Under Windows all programs write to the Video Screen Map, so all programs executed are aware of each others' screen I/O.
Under UNIX, each program executed implements its own screen map. That means that none of the programs executed are aware of any other program's screen I/O. Thus, using screen I/O for programs executed using CBL_EXEC_RUN_UNIT under UNIX can lead to unexpected results.
The UNIX file system is case sensitive. The Windows file system is not.
Applications developed on UNIX that are to be run on Windows should not differentiate the names of called subroutines or data files by case alone.
Applications developed on Windows that are to be run on UNIX must use called subprogram names and data filenames that match exactly the names of the physical files on the file systems.
The default extension for intermediate code on Windows is .INT (all upper case). On UNIX the default extension is .int (all lower case). When moving intermediate code created on Windows to UNIX, you must change the case of the intermediate code file extension. Using the UNIX Bourne shell, the following commands make the necessary change to all file names in the current directory that have the extension .int:
for i in *.INT
do
mv $i `basename $i INT`int
done
Similarly, each overlay for a segmented program has an extension in the format .Inn. On Windows the "I" is upper case, while on UNIX it is lower case. These extensions also must be changed to the correct case.
On Windows the separator for directories in a path to a file is the backslash character (\). On UNIX it is the forward slash character (/). However, on Windows "/" is recognized when used in a COBOL program, so you should use "/".
Obviously, if paths to files are specified in a program, then the relevant directory structure must exist on all machines where the program is to be run.
Windows recognizes drive identifiers (for example, a:) in paths. UNIX would assume these to be part of the filename. Therefore, you should not use drive identifiers.
Net Express and Mainframe Express support certain PC-specific features. Generally these take advantage of the special video characteristics of the IBM PC, PS/2, and compatibles.
The most important is the IBM Extended Graphics Character Set. On Windows, you can include eight-bit graphics characters in your source code. Some UNIX systems support only seven-bit characters; the eighth bit might be stripped from your source when you use a UNIX editor such as vi. Other UNIX systems support different eight-bit character sets, for example the ISO 8859-1 character set.
Therefore, eight-bit characters input on one operating system might appear different on another. You should avoid using characters from extended character sets unless you are certain that your target operating system and hardware support them. Alternatively, use the generic character routines CBL_GET_SCR_LINE_DRAW and CBL_GET_SCR_GRAPHICS which supply the nearest equivalent characters to be used for line drawing and graphics in all environments.
Most UNIX terminals cannot detect the Alt or Ctrl key being pressed unless another valid key is pressed at the same time. Avoid using these keys by themselves.
See the section Control and Alt Key Support in the chapter Terminfo Database and Terminal Devices in your Server Express User's Guide.
The value returned by some COBOL operations is specified in the Language Reference as undefined; for example, dividing by zero, or using data that does not conform to a picture clause. If you were to examine the values actually returned by these operations, you would find that they differ according to the executable file format and the COBOL system on which the program was compiled.
For example, a divide-by-zero operation might return a different value in an intermediate code program to that returned in a generated code program.
You should ensure that the results or logic of your program do not depend on the results of operations specified as giving undefined results. For example, as the result of a divide-by-zero operation is unpredictable, you should always use the ON SIZE ERROR phrase if you want a specific action or procedure to be performed depending on this result. See the description of ON SIZE ERROR in your Language Reference for more details.
The individual bytes of items described as COMP-5 are stored in the order in which they would be stored by the machine code of the host machine. This means their internal representation might differ depending on the computer on which the program is being run. Therefore, avoid redefining COMP-5 items or writing COMP-5 data items to files.
Do not embed directives that affect generated code in the source of your program (using $SET); they might not be meaningful on all machines where the program is to be run.
Applications that use the ROLLBACK phrase are only portable within the Fileshare Version 2 environment. For non-Fileshare Version 2 environments, the ROLLBACK phrase causes all record locks to be released for all UNIX systems, and on Windows systems if the CALLFH Compiler directive has been specified.
All file types are portable between Server Express and Net Express or Mainframe Express. However:
For information on File Handler configuration, see the chapter File Handler Configuration in your File Handling book.
Copyright © 2000 MERANT International Limited. All rights reserved.
This document and the proprietary marks and names
used herein are protected by international law.
| Creating 64-bit Programs | Internationalization Support | |