Compatibility Considerations for COBOL and C
MPE documents | |
 Complete PDF | |
| Table of Contents | |
| Index |
Support Technology Lab This article discusses compatibility concerns relating to HP COBOL II/iX and HP C/iX on MPE/iX 6.5. These concerns are the result of enhancements to provide better language support for 64-bit integers.The project to improve support for 64-bit integers involved changes to four products.
The C/iX compiler was enhanced to provide full support for "long long" integers. Details can be found elsewhere in this Communicator.
Seven new routines were added to the Millicode libraries, MILLI.LIB.SYS and /lib/libmilli.a, to perform highly optimized arithmetic operations on 64-bit integers. The entry points for these new routines are $$mul2U, $$mulo2U, $$mul12U, $$div2I, $$div2U, $$rem2I, and $$rem2U.
The C/iX Library was enhanced with two new functions to convert from strings to 64-bit integers. These are strtoll() and strtoull(). In addition, the printf() and scanf() families of functions were enhanced to recognize an optional ll (ell ell) modifier to specify that the corresponding argument is a long long integer.
The COBOL II/iX compiler was updated to generate code that takes advantage of the new 64-bit Millicode routines.
Forward Compatibility Not a Problem
Hewlett-Packard strives to maintain forward compatibility from one release of MPE to the next. MPE/iX 6.5 is no exception. Applications developed on previous releases of MPE/iX should continue to run without needing to be recompiled or relinked. Furthermore, whenever an application is recompiled on MPE/iX 6.5, it should not be necessary to make any changes to the source code or to the procedures for compiling, linking, and running.
Backward Compatibility Not Guaranteed
In general, HP does not guarantee that an application can be developed on one release of MPE/iX and then executed on an earlier release without change. Although code that is compiled using the latest release can often be moved successfully to a system on an older release, doing so is generally not supported. As is explained below, moving executable programs and executable libraries from MPE/iX 6.5 to a pre-6.5 system probably works in many cases. However, there are situations where special procedures might be required if you want to avoid having to recompile or relink on the earlier system.It isn't possible to enumerate all of the situations in which problems might be encountered when moving backward to a pre-6.5 system. If you encounter difficulties in doing so, you may be able to find workarounds. Remember, though, that in some situations it may be necessary to recompile in order to move an application from MPE/iX 6.5 to an earlier system.
COBOL/iX
Backward compatibility for COBOL II/iX executable programs (NMPRGs) and executable libraries (NMXLs) should not be a problem. If your COBOL code generates calls to any of the new Millicode routines, those routines will be copied from the Millicode library and bound into your program or XL. The absence of the latest Millicode library on the target machine is not a problem, because the Millicode library is a relocatable library and is not accessed at run time. However, if you compile a COBOL II/iX program on an MPE/iX 6.5 system and try to link it on a pre-6.5 system, you may have unresolved externals because of calls to the new Millicode routines. These unresolved externals might be reported at link time, but it is possible that the problem would not show up until load time, with unrelated errors reported by the RUN command. The recommended procedure is to link on the 6.5 system, where the latest Millicode library is available.
C/iX
As with COBOL II/iX, the C/iX compiler may take advantage of the new Millicode routines, even in programs that don't use the new "long long" 64-bit integer data type. If you compile and link on a 6.5 system, you will probably not have difficulty moving a C/iX executable program (NMPRG) to a pre-6.5 system. But if you compile on a 6.5 system and try to link on a pre-6.5 system, you may encounter unresolved externals or unrelated load-time errors, especially if you use 64-bit integers. There are additional considerations to be aware of if you use the 64-bit integer functionality of the C/iX Library. If you do so, and if you want to move your code to a pre-6.5 system, you need to be sure to link with LIBC.LIB.SYS, the relocatable library that contains the entire C/iX Library. If you link with LIBCINIT.LIB.SYS or LIBCSHR.LIB.SYS instead, and then move your program to a pre-6.5 system, there are two problems you are likely to encounter. First, if you have called strtoll() or strtoull(), you will have unresolved externals, because these functions do not exist in the C/iX Library in XL.PUB.SYS on pre-6.5 systems. Second, you will experience strange behavior if you use 64-bit integers with the printf() and scanf() families of functions. The pre-6.5 versions of these functions do not recognize the ll modifier for long long integers and will produce incorrect results.
Not Supported, but Might Work
In summary, it is not supported to compile code on any release of MPE/iX and then move it to an earlier release, even though it often works. If you try to move code from an MPE/iX 6.5 system to a pre-6.5 system, if it doesn't work, the following are the most likely symptoms.You get unresolved externals for $$mul2U, $$mulo2U, $$mul12U, $$div2I, $$div2U, $$rem2I, or $$rem2U. If the unresolved externals go undetected, you get strange, unrelated errors at load time. This could happen with COBOL II/iX or C/iX.
You get unresolved externals for strtoll() or strtoull(). This could happen if you use these new C/iX Library functions for converting 64-bit integers.
Your printf() and scanf() calls produce incorrect results. This could happen if your code uses the new functionality for handling 64-bit integers with these functions.
|
NEWCI Command (CI Elimination) |
C/iX Supports 64-bit Integers |