|Portability Issues||Internationalization Support|
This document gives you information on migrating 16-bit applications developed using the Micro Focus COBOL System to 32-bit Object COBOL applications for use on 32-bit platforms. The following areas must be taken into consideration:
This chapter also describes the Cblnames and Cbllink utilities, and describes how to use the Object COBOL system on both 16-bit and 32-bit operating systems.
These areas are discussed in the following sections.
CCI user-level filenames are different for 32-bit. They are as follows:
where xx represents the protocol supported, and is one of the following:
|NP||Named Pipes (CCINAMP)|
|AS||Asynchronous Communications (CCIASYNC)|
|DE||Windows Dynamic Data Exchange (CCIDDE)|
On 32-bit OS/2 the modules available are:
On Windows NT the modules available are:
In all environments where CCITP process registration demons are available this module is provided as ccitcp2.exe.
The following Compiler directives which were available in the 16-bit COBOL product are not required on 32-bit Object COBOL systems:
The reasons why these directives are not required on 32-bit COBOL systems is as follows:
|64KPARA, 64KSECT, SEGCROSS, SEGSIZE, SMALLDD, TABLESEGCROSS||These directives were needed to create programs with
more than 64Kb of code or data on a 16-bit segmented architecture. The
32-bit Object COBOL systems do not have to deal with segmentation of
this sort, so the directives are not needed.
|AUXOPT, DATALIT, EXPANDDATA, FIXING,
OPTSIZE, OPTSPEED, PROTMODE
||These directives controlled optimizations that are
generally handled automatically by the 32-bit Compiler.
|BADSIGNS||This directive is synonymous with HOSTSIGNS, which is
the preferred directive name.
|EANIM||This directive governed the creation of debug
information for Microsoft Codeview on 16-bit platforms.
|FASTLINK||The optimization governed by this directive is not
available on Object COBOL V4.0.
|MASM||The MASM directive was used to create assembler
listing files (with the file extension .grp) which would be
acceptable to the Microsoft MASM assembler. On the 32-bit COBOL systems,
the assembler listing files are already very close to the format
required by MASM.
|MODEL||The MODEL directive controlled the production of
special object files for the 16-bit product and, as such, is not
relevant to the 32-bit product.
|PARAMCOUNTCHECK||This directive was provided because the method used by
the 16-bit product to communicate the number of parameters passed from a
calling program to a called program (using the CX processor register)
could have clashed with other uses of the register in mixed-language
programming environments. The method used by the 32-bit generator is
immune to such problems, so the directive is not needed.
|PARAS||This directive is not supported in the 32-bit product.
|REGPARM||This directive enabled you to create object modules
that could interface with modules created by other 16-bit compilers.
This is not relevant to the 32-bit environment.
|SIGNCOMPARE||The functionality covered by this directive is largely
provided by the HOSTSIGNS directive.
|TRICKLECHECK||This directive was provided to enable you to create
programs that would produce error messages if their flow of control
trickled. This could then be used to determine whether or not to apply
the optimization provided by the TRICKLE directive. The 32-bit code
generator automatically detects trickling in a program, and switches
this optimisation on and off accordingly. Thus, there is no need to
compile with TRICKLECHECK and run the program to find out whether the
It is not necessary to remove these directives from your existing code, batch files, .dir files or $SET statements, as the Compiler issues an "Ignored" message and continue compiling.
The directive GNT is used to create generated code for use by the Run Time Environment. The 16-bit directive OMF"GNT" is also supported and has the same effect.
The following directives are available in both the 16-bit and 32-bit products but are intended for use only when running the 16-bit product:
You should remove these from your code for 32-bit applications.
The ASMLIST directive is supported but behaves differently under the 32-bit Object COBOL system.
The TARGET directive is supported under the 32-bit Object COBOL system, but does not accept arguments pertinent to the 16-bit COBOL system.
The TRICKLE directive is supported by the 32-bit Object COBOL but is generally not needed, as the 32-bit Compiler can work out if a program trickles.
For full details on Compiler directives available with 32-bit Object COBOL, see the chapter Directives for Compiler in your Object COBOL User Guide.
The call-by-number routine x"d0" is now superceded by the CBL_ALLOC_MEM routine, which you should use by preference.
Memory allocated using the call-by-number routine x"d0" is always initialized to spaces in this product. In the 16-bit product, if the DEFAULT-BYTE directive was used to set the default filler byte to a value other than the default (spaces), x"d0" memory was initialized to that new value. Although not documented behavior, your program might be relying on this. Ensure that you explicitly initialize any x"d0" data, rather than relying on what the run-time has initialized it to.
The following three call-by-name routines are available only on 16-bit COBOL systems:
|CBL_SCR_CREATE_VC||Create an alternative colormap|
|CBL_SCR_ALLOCATE_VC_COLOR||Store colors in the virtual colormap|
|CBL_SCR_DESTROY_VC||Reinstate the system colormap|
The routines for creating and handling virtual color maps are available on the 16-bit COBOL system only.
Calls that are coded using the "__" (double-underscore) prefix should be recoded to use call convention 8. We strongly recommend this method for forcing a LITLINK call. If you need to litlink calls using the double underscore convention, then you should compile the program using the LITLINK(2) Compiler directive.
You can statically link individual calls by using call convention 8. Using this call convention on a CALL literal statement causes the Compiler to declare the literal as a public symbol, so it is resolved at link time, rather than at run time. This call convention can be combined with other call conventions. For example, call convention 10 gives a static linked call to a sub-program which removes the parameters from the stack.
The following run-time switches, which are available in the 16-bit COBOL product, either are not available or have a different meaning in 32-bit Object COBOL:
* These switches have a different meaning in 32-bit Object COBOL.
If your application is explicitly reading or setting any of these switches, you should remove these dependencies on them.
DOS, Windows and OS/2 :
On DOS, Windows and OS/2, this COBOL system includes a simplified link utility called Cbllink. You can use this utility to compile and link programs to an executable module. To use this utility, you must store the Cblnames utility, and the Linker and Library Manager utilities, in one of the directories indicated by the PATH environment variable.
By default, any system programs required by a COBOL program, for example Adis or Mffh, will automatically be linked into the executable module by this utility. You can instruct Cbllink to link the system program separately if required.
See the chapter Using Cbllink in your Object COBOL User Guide for details.
32-bit Windows and OS/2 :
On 32-bit Windows and OS/2 Object COBOL systems, if you want to link your programs using the Linker you must first run the Cblnames utility. If you have used Cbllink, you do not need to use the Cblnames utility: Cbllink invokes Cblnames, and so does everything necessary to create .exe and .dll modules. The Cblnames utility is provided in case you want to ignore Cbllink, and compile and link your programs yourself.
For information on using the Cblnames utility, see the chapter Using Cblnames in your Object COBOL User Guide.
On 32-bit Object COBOL systems you can configure certain run-time behavior through the following run-time configurables:
See the chapter Run-time Configuration in your Object COBOL User Guide for details.
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 exectuable 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. Similarly, the value returned in a program compiled on the 16-bit COBOL system might be different from the value returned in the same program compiled on a 32-bit COBOL system.
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.
3-D objects drawn using Panels Version 2 look smaller on 32-bit COBOL systems for Windows than on the 16-bit COBOL system. The 32-bit COBOL systems for Windows use the native Windows 95 or Windows NT 3-D effects, instead of the public domain DLL used by the 16-bit COBOL system.
On the 16-bit COBOL system, a 3-D sunken border is drawn around the outside of controls such as entry fields, list boxes and combo boxes. With the native effects, the border is drawn around the inside of the controls, so the resulting controls look smaller.
Copyright © 1999 MERANT International Limited. All rights reserved.
This document and the proprietary marks and names used herein are protected by international law.
|Portability Issues||Internationalization Support|