On a big-endian machine such as the z/OS hardware, CHARVAR(1:1) contains the most significant (higher-order) byte of
BINVAR. However, on a little-endian machine, with the same code,
CHARVAR(1:1) will contain the least significant (lower-order) byte of
BINVAR; this is definitely a change of behavior and will probably lead to different observable results. However, the Rehosting Workbench COBOL Converter is unable to detect and fix all occurrences of this situation (the example above is "obvious", but there exists many much more complex cases); these must be handled manually.
As mentioned in the previous paragraph, the Rehosting Workbench COBOL converter translates portable binary integer types (BINARY, COMP, COMP-4) to the native binary type COMP-5. In addition to endianness problems, this may cause another kind of difference of behavior for applications which were compiled with the (default) TRUNC(STD) option on the source platform – this option corresponds to the
TRUNC option of Micro Focus COBOL or the
BINARY-TRUNCATE option of COBOL-IT. Indeed, both on the source and on the target platforms, the portable binary types obey this option whereas the native type does not. In general, the probability of observing a real difference of behavior is very low, because in general, binary-integer variables are used to hold "control" values (loop counters, array indices, etc.) rather than applicative values. In any case, if differences of behavior are observed, it is up to the Rehosting Workbench user to deal with them, either by accepting them or by manually correcting them, for instance by returning a few selected variables to their original binary type.
In most cases, if you comply correctly with these directives, the resulting application will run smoothly. There is one issue however, for which no efficient solution can be found: the collating sequences of the EBCDIC and ASCII character sets are not quite the same, and this may lead to different behavior in sorting and string comparisons. In most cases, there is no problem, because you sort or compare "homogeneous" data such as names (alphabetic) or dates (numeric); only special characters such as accented letters may sort a bit differently but still satisfactorily. However, in cases when you sort or compare data which contains mixed letters and digits, you may find differences of behavior, because letters sort before digits in EBCDIC and after digits in ASCII. One typical example is when you compute a key for some type of data (account number, etc.) using both digits and letters. The COBOL converter cannot handle such issues because these are dynamic issues related to the contents of COBOL variables, not static issues related to their declarations.
As mentioned above, string or character literals in COBOL programs, including hexadecimal string literals, are subject to EBCDIC-to-ASCII conversion. This is legitimate when these literals denote texts or pieces of text. Sometimes however, such constant values denote (numeric) codes such as file status codes, condition codes, CICS-related values, etc. In this case, it is generally not appropriate to apply EBCDIC-to-ASCII conversion to these values. However, the COBOL converter, like any automatic tool, cannot reliably "guess" the semantic nature of a COBOL variable or literal, so it cannot handle itself these exceptions; this will have to be done manually using post-translation, see post-translation-file Clause).
Source floating-point variables (COMP-1 and
COMP-2) types are "translated" to the same types on the target platform. Given this, the Micro Focus COBOL compiler and run-time system offer the possibility to use floating-point data (
COMP-1 and
COMP-2 variables) in either the IBM hexadecimal format or the native (IEEE 754) format. If the
NONATIVEFLOATINGPOINT option is set at compile time (which is true by default), then the floating-point format is selected at run-time, depending on the
MAINFRAME_FLOATING_POINT environment variable and/or the
mainframe_floating_point tunable:
|
•
|
MAINFRAME_FLOATING_POINT environment variable set, or mainframe_floating_point tunable set to true: the IBM format will be used.
|
|
•
|
MAINFRAME_FLOATING_POINT environment variable unset, and mainframe_floating_point tunable unset or set to false: the native format will be used.
|
|
•
|
On the source platform, COMP-1 and COMP-2 types have the same representation range, from about 10 -79 to 10 76, whereas on the target platforms (which all natively support the IEEE 754 format), the range for COMP-1 is about from 10 -45 to 10 38 and the range for COMP-2 is about from 10 -323 to 10 308. So the tradeoff between range and precision is different on both platforms.
|
By default, data files which are SEQUENTIAL on the source platform are translated into
LINE SEQUENTIAL files on the target platform, to be more "usable". In general, this is a good choice and such files are well supported by the target COBOL system. However, there is a catch: since such files are inherently of variable record size, a
REWRITE operation may cause unpredictable results and differences of behavior (see the Micro Focus and COBOL-IT documentation). If you are not sure that
REWRITE operations on a given
SEQUENTIAL file would always succeed if that file is turned into a
LINE SEQUENTIAL one, we advise to keep it purely
SEQUENTIAL; this can be done by inserting its description in the configuration sub-file referenced by the
pure-seq-map-file clause below.
On the source platform, a variable of type POINTER occupies 4 bytes in memory (32 bits); on all the supported target platforms, based on 64-bit operating systems, such a variable occupies 8 bytes. This may lead to various kinds of differences of behavior for which we take no responsibility:
|
•
|
Technical redefinitions: if a POINTER variable is directly redefined by a PIC X(4) or PIC S9(9) COMP variable used to manipulate the representation of the pointer values, the redefining variable and the code dealing with it will have to be manually rewritten. However, we strongly discourage such machine-dependent "hacks".
|
|
•
|
Structure alignments: if a POINTER variable is part of a structure containing variants (redefinitions), and if the different variants (sub-structures) are designed so that one particular field of one variant must be aligned with (have the same location as) some other field in some other variant, then this property must be maintained after the POINTER variable changes size: compensation fillers must be inserted, etc. Again, this must be handled manually. Note that such intended alignments must be maintained across redefinitions, but also across MOVEs to other structures.
|
|
•
|
Structure size: if a POINTER variable is part of a structure which is moved to some unstructured PIC X(…) variable which was big enough to hold the structure before the POINTER variable changes size, then you must make sure that it is still the case after the change.
|
|
•
|
On z/OS and AIX, NULL is address 0 and this is considered as a legal address, so when the parameter is accessed, you get whatever is stored at that address (possibly with unpredictable results).
|
The representation of the NULL pointer value may vary from one platform to another, in particular between the source and target platforms – if only because they don't have the same size, like every other pointer value. In consequence, every program which assumes a specific representation for this value, for instance by "casting" it to or from some binary integer value, may have a different behavior from one platform to another. The COBOL converter cannot handle this issue by itself, automatically, and it will have to be handled manually. Anyway, we strongly discourage such machine-dependent "hacks".
This file is given to the COBOL converter using the -c or
-config mandatory command-line option. It defines various "scalar" parameters influencing the conversion and points to subordinate files containing "large" configuration data, such as renaming files.
This clause specifies the target SQL syntax. Its value can be oracle or
none. If the value is
none, the sql code in the source files isn't translated. It's transferred as it is to the target components. The default value of this clause is
oracle. In the latter case, it's not necessary to set
sql-rules to
oracle in the configuration file.
|
•
|
If the keep-same-file-names clause is given, the converted programs and copy files will have the same file extensions as the original files in the source asset (as cataloged). The other clauses, if given, will be ignored.
|
|
•
|
If the target-program-extension clause is given, then the converted programs will have the given file extension,
|
|
•
|
If the target-copy-extension clause is given, then the converted copy files will have the given file extension.
|
This clause specifies that the copy-reconciliation process crp is to be deferred until after the conversion is completed; this allows COBOL conversion to run in multiple concurrent processes. By default, in the absence of this clause, the copy-reconciliation process is executed incrementally immediately after each program is converted, which mandates single-process execution. See the copy-reconciliation process below for more details.
When present, this clause specifies that the what-string containing conversion timestamp and converter version information, which the converter normally inserts at the beginning of every converted file, is not to be printed out in this execution. This will be seldom used, unless you really want to hide the fact that your application is migrated using the Rehosting Workbench!
When the rename-copy-map-file Clause is not present, or when this file is empty, no copy renaming takes place. It is an error when the file cannot be found or read, or when the same
original-copy-name;original-library-name combination is associated with different
new-copy-names in different lines of the file. In this case, the converter stops with an error message and does not convert any programs. Note however that it does not check whether two different copy files in the same directory are renamed to the same target file. In principle, this would be handled gracefully by the copy reconciliation process, but without guarantee.
When the rename-call-map-file Clause clause is not present, or when this file is empty, no call renaming takes place. It is an error when the file cannot be found or read, or when the same original-call-name is associated with different new-call-names in different lines of the file. In this case, the converter stops with an error message and does not convert any programs. Note however that it does not check whether two different subprograms in the same directory are renamed to the same target file.
This file is associated with the hexa-map-file Clause above. Its contents are an EBCDIC-to-ASCII conversion table to apply to characters in hexadecimal form (characters in textual form are supposed to be converted at the same time as the source file itself). The syntax is simply a CSV file with a semicolon as separator. Each line is in the form:
The script automatically generates the tr-hexa.map file inside the current directory (
PARAM directory is a better choice). This generated file name has to be used as
file-path value with the
hexa-map-file attribute.
These files are associated with the conv-ctrl-file Clause and alt-key-file Clause. They contain information about file-to-RDBMS conversion, e.g. to define which logical files (FDs) are converted into RDBMS tables (actually, because the physical files they are associated with are converted to these DB tables). Since these files are automatically generated by the Rehosting Workbench File-to-Oracle conversion tool and should not be modified by hand, their contents are not further specified here.
This file is associated with the sql-stored-procedures-file Clause. Its contents are a list of subprogram names, one per line. When one of these names appears in a COBOL CALL statement, the latter is replaced by an SQL CALL statement. In addition, declarations of the parameters of the CALL, if any, are adapted so that they can be used in SQL statements.
with both names being symbols. The effect of such a line is to prevent this particular logical file (the given FD in the given program), assumed to be (record)
SEQUENTIAL on the source platform, to be converted to
LINE SEQUENTIAL on the target platform; rather, it is kept unchanged as a record
SEQUENTIAL file. This makes it much less amenable to manipulation using standard target-platform utilities, but on the other hand, it will support unrestricted
REWRITE operations (see section
REWRITE operations on
LINE SEQUENTIAL files above). This might also be useful for files exchanged with a z/OS platform in binary form.
If file ORIGCOPY(.s-ext) is translated into multiple versions, these versions are named
ORIGCOPY(.t-ext),
ORIGCOPY_V1(.t-ext),
ORIGCOPY_V2(.t-ext), etc.
When the COBOL Converter applies a transformation rule to a piece of code, it attempts to keep the same layout for the new code, by minimizing how elements of the code which exist in both the original and new versions are moved around. In addition, when the converter inserts a new element, for instance a statement or a variable declaration, it tries to align the new element with similar ones before or after it. When, by following these guidelines, a transformed or new line of code becomes too long for the fixed format, the converter cuts the line at the right-most "nice" cutting point (preferably between two words) and wraps the rest on the next line, flush with the right margin, to indicate that these wrapped elements are logically part of the previous line.
Causes “default” ACCEPT statements to read from the specified logical file instead of from the Unix standard input file. This is the same behavior as on the source platform and is appropriate with ART-translated KSH scripts, which treats
SYSIN as any other file for COBOL programs.
Causes “default” DISPLAY statements to write to the specified logical file instead of to the Unix standard output file. This is the same behavior as on the source platform and is appropriate with the Rehosting Workbench-translated KSH scripts, which treat
SYSOUT as any other file for COBOL programs.
Enables the same behavior as on the source platform regarding nested PERFORM statements with overlapping ranges. The default option
PERFORM-TYPE"MF" is semantically cleaner and allows more efficient execution, but may lead to differences of behavior which are hard to detect and diagnose; hence, unless you know that your
PERFORM ranges are “well-behaved” and never overlap, we can’t recommend the default setting.
Directs the MicroFocus compiler to use, by default, the EXTERNAL file-assignment method. In this method, the
SELECT names are used as keys to search the actual file names in environment variables of the form
DD_NAME. This is the mode chosen for the Rehosting Workbench, because it allows the file assignments to be specified outside the programs, namely in the calling KSH scripts. Not only is this closer in philosophy to the source behavior, but in our opinion this is the most flexible method.
When ZEROLENGTHFALSE is set, all comparisons between zero-length group items, and between zero-length items and figurative constants, return false; when it is not set, they all return true. To reproduce the same behavior as on the source platform, it must be set.
Does not truncate names of subprograms referenced in CALL statements. This is necessary for the Rehosting Workbench-migrated assets, because data access routines generated by the Rehosting Workbench have long names. In addition, in future evolutions of the asset, you will want to get rid of the short-names limitations imposed on the source platform.
Does not truncate names of copy files referenced in COPY directives. This is necessary for the Rehosting Workbench-migrated assets, because copy files generated or inserted by the Rehosting Workbench have long names. In addition, in future evolutions of the asset, you will want to get rid of the short-names limitations imposed on the source platform.
NOSIGN-FIXUP provides emulation of the mainframe compiler option
NUMPROC(PFD) when using the
HOST-NUMCOMPARE and
HOST-NUMMOVE directives. This option gives the best performance, given that it is not possible to provide a complete emulation of
NUMPROC(NOPFD) behavior.
checks that each index is between the correct bounds when accessing an array or in reference modifiers. This is similar to the SSRANGE option of the IBM compiler. We strongly recommend that both of these options be set, at least during migration tests and in the first few months of operation (note that setting
SSRANGE also sets
BOUND). This choice is a bit controversial because it can break some programs which apparently run correctly on the source platform (without the
SSRANGE option). However, in our experience, the only programs which break are incorrect programs which just happen to work by chance on the source platform and would not work in the same way, or at all, on the target platform. The sooner we detect these programs and fix them, the better. In the same way, you could consider setting the
CHECK option, which enables various (other) kinds of run-time checks and allows to detect other kinds of seemingly-correct programs.
specifies whether truncation to the given PIC size occurs when assigning a value to a
BINARY variable (or
COMP, or
COMP-4). This is similar to the
TRUNC(STD) option of the IBM compiler. However, with the present specification of the ART COBOL converter, all such variables are transformed into
COMP-5 variables, which do not obey the
TRUNC option. See the discussion in
Use of COMP-5 type and the TRUNC compiler option above.
forbids the presence of ALTER statements in the COBOL programs. Since
ALTER statements are a thing of the past, and a very bad thing if any, we recommend that you take the opportunity of migrating your asset with the ART Workbench to chase out any remaining
ALTER. Then, set this option to prevent their reappearance and to make compiled code more efficient and safe.
Controls behavior for alphanumeric moves between overlapping data items. If BYTE-MODE-MOVE is specified, data is moved one byte at a time from the source to the target. If
NOBYTE-MODE-MOVE is specified, the data is moved in granules of two, four or more bytes at a time (depending on environment) from the source to the target. Consequently, if the overlap is less than the size of the granule, each granule moved overwrites part of the next granule to be moved.
NO-BYTE-MODE-MOVE gives better performance, but may yield incorrect code on some very rare programs which work correctly on the source platform; we suggest that you start with the “more compatible” setting (
BYTE-MODE-MOVE), perform complete regression tests until satisfaction, then choose the other option and re-test.
Specifies that CANCEL statements are not to be ignored. This is similar to the IBM option of the same name (but not quite the same, see the MicroFocus documentation). We strongly recommend that you set this option, because the Tuxedo servers in the ART TP Run-time system, which execute the applicative CICS programs, use
CANCEL statements to free the memory used to load and run those programs. If
NODYNAM is in effect, the amount of memory use by these servers would grow as they execute more and more different programs.
|
•
|
DIALECT"MF" (default): sets the most "native" and efficient mode of operation. Since the aim of Oracle ART is not simply to emulate the source mainframe, but to forget about it and lead you towards the benefits of the target platform, this is the best choice. It will enable you to use the modern features of MF Cobol such as Unicode support and object-oriented programming.
|
|
•
|
CHARSET" ASCII" (default): sets the default character set and collating sequence to those supported natively on the target platform. This is an obvious choice, too.
|
|
•
|
SOURCEFORMAT" FIXED" (default): directs the compiler to stick with the "old" standard, fixed-format, column-based format. This may appear contradictory with our aim at modernity, but unfortunately the Oracle Pro*Cobol compiler, even the latest 11g version, is still not quite compatible with the MicroFocus free format, and we have to require fixed format to guarantee correct behavior.
|
|
•
|
ALIGN" 8" (default): defines the alignment for top-level structures (01 and 77-level). Required to make sure that structures retain the same layout as on the source platform, and yields the best performance, at a slight expense in memory size.
|
|
•
|
COMP5-BYTE-ORDER" NATIVE" (default): uses native byte ordering for COMP-5 variables. Necessary for compatibility with the C language and the ART TP run-time system.
|
|
•
|
P64 (to set explicitly): compiles for 64-bit platforms. All the target platforms supported by ART are 64-bit.
|
|
•
|
SIGN" EBCDIC" (to set explicitly): uses the EBCDIC convention rather than the ASCII convention for representing overpunched sign on DISPLAY numeric values. This is the same convention as on the source platform and hence provides for less differences of behavior when the last digit of such a numeric value is redefined by a character variable.
|
|
•
|
DEFAULTBYTE" 00" (to set explicitly, except if the previous option is given): specifies the value with which to initialize all otherwise-undefined variables in the Working-Storage Section. Not strictly necessary, since on the source platform, the Working-Storage Section is officially not implicitly initialized, but we found that it leads to less differences of behavior when a numeric variable is redefined by a character variable.
|
|
•
|
RWHARDPAGE (to set explicitly): Causes the Report Writer control module to execute a form feed after the last item has been printed on a page, instead of the usual multiple blank lines. All Unix printer systems correctly handle Form Feed characters.
|
|
•
|
INDD or INDD" SYSIN80L" (to set explicitly): causes "default" ACCEPT statements to read from the specified logical file instead of from the UNIX standard input file. This is the same behavior as on the source platform and is appropriate with ART-translated KSH scripts, which treats SYSIN as any other file for Cobol programs.
|
|
•
|
OUTDD or OUTDD" SYSOUT80L" (to set explicitly): causes "default" DISPLAY statements to write to the specified logical file instead of to the UNIX standard output file. This is the same behavior as on the source platform and is appropriate with ART-translated KSH scripts, which treat SYSOUT as any other file for Cobol programs.
|
|
•
|
HOSTARITHMETIC, HOST-NUMMOVE"2", HOST-NUMCOMPARE"2", ARITHMETIC"ENTCOBOL", CHECKDIV"ENTCOBOL", FP-ROUNDING"ENTCOBOL", REMAINDER"2" (to set explicitly): all these options control various aspects of the treatment of numeric variables and expressions. Their settings maximizes the compatibility with the source platform.
|
|
•
|
IBMCOMP (to set explicitly): turns on word-storage mode for the layout of the structures, the same mode as on the source platform and also the one yielding the most efficient performance, at a slight increase in memory consumption.
|
|
•
|
ODOSLIDE (to set explicitly): Moves data items that follow a variable-length table in the same record as the table's length changes. This affects data items that appear after a variable-length table in the same record; that is, after an item with an OCCURS DEPENDING clause, but not subordinate to it. With ODOSLIDE, these items always immediately follow the table, whatever its current size; this means their addresses change as the table's size changes. With NOODOSLIDE, these items have fixed addresses, and begin after the end of the space allocated for the table at its maximum length. Setting ODOSLIDE leads to the same behavior as on the source platform.
|
|
•
|
PERFORM-TYPE"ENTCOBOL" (to set explicitly): enables the same behavior as on the source platform regarding nested PERFORM statements with overlapping ranges. The default option PERFORM-TYPE"MF" is semantically cleaner and allows more efficient execution, but may lead to differences of behavior which are hard to detect and diagnose; hence, unless you know that your PERFORM ranges are "well-behaved" and never overlap, we can't recommend the default setting.
|
|
•
|
RDW (to set explicitly): Enables you to find out the length of a record that has just been read from a variable-length sequential file, by providing a "hidden" length variable just before the first record of the FD (see more details in the Micro Focus documentation). This "trick" is available on the source platform, although not explicitly advertised, and this option allows to reproduce the same behavior.
|
|
•
|
RECMODE" ENTCOBOL" (to set explicitly): directs the Micro Focus compiler to use the same algorithm as the source compiler to determine whether a file has fixed-length or variable-length for-mat, depending on the length of the various records in the file definition.
|
|
•
|
ASSIGN" EXTERNAL" (to set explicitly): directs the MicroFocus compiler to use, by default, the EXTERNAL file-assignment method. In this method, the SELECT names are used as keys to search the actual file names in environment variables of the form DD_NAME. This is the mode chosen for ART, because it allows the file assignments to be specified outside the programs, namely in the calling KSH scripts. Not only is this closer in philosophy to the source behavior, but in our opinion this is the most flexible method.
|
|
•
|
SYSPUNCH"80" (to set explicitly): defines the record length for the SYSPUNCH logical file. Default setting (132) is not the same as on the source platform.
|
|
•
|
ZEROLENGTHFALSE (to set explicitly): When ZEROLENGTHFALSE is set, all comparisons between zero-length group items, and between zero-length items and figurative constants, return false; when it is not set, they all return true. To reproduce the same behavior as on the source platform, it must be set.
|
|
•
|
NOADV (default): don't use special printer-control characters on text files. Target-platform print-ing utilities will simply print a file with the same layout as it appears on the screen.
|
|
•
|
NOTRUNCCALLNAME (default): does not truncate names of subprograms referenced in CALL state-ments. This is necessary for ART-migrated assets, because data access routines generated by ART have long names. In addition, in future evolutions of the asset, you will want to get rid of the short-names limitations imposed on the source platform.
|
|
•
|
NOTRUNCCOPY (default): does not truncate names of copy files referenced in COPY directives. This is necessary for ART-migrated assets, because copy files generated or inserted by ART have long names. In addition, in future evolutions of the asset, you will want to get rid of the short-names limitations imposed on the source platform.
|
|
•
|
NOCOPYLBR (default): treat copy-file names as plain paths, not library archives (.lbr files). This is necessary for ART-migrated assets, because copy files converted or generated by ART are not grouped in archives.
|
|
•
|
REPORT-LINE"256" (default): Specifies the maximum length of a Report Writer line.
|
|
•
|
COPYEXT"cpy,cbl" (to set explicitly): Specifies the filename extension of the copyfile that the compiler is to look for if a filename in a COPY statement is specified without an extension. This non-default setting is appropriate for AST-migrated asset, because copy files generated by ART always have the .cpy extension and copy files converted by ART generally have the same extension. However, if you configure the Cobol converter for another extension, you will have to adapt the setting of this option appropriately.
|
|
•
|
FOLDCALLNAME"UPPER" (to set explicitly): directs the compiler to map subprogram names in CALL statements to upper case.
|
|
•
|
FOLDCOPYNAME"UPPER" (to set explicitly): directs the compiler to map copy file names in COPY directives to upper case.
|
|
•
|
MAPNAME (to set explicitly): Makes the Compiler alter program-names and entry-point names to make them compatible with the source platform.
|
|
•
|
BOUND and SSRANGE check that each index is between the correct bounds when accessing an array or in reference modifiers. This is similar to the SSRANGE option of the IBM compiler. We strongly recommend that both of these options be set, at least during migration tests and in the first few months of operation (note that setting SSRANGE also sets BOUND). This choice is a bit controversial because it can break some programs which apparently run correctly on the source platform (without the SSRANGE option). However, in our experience, the only programs which break are incorrect programs which just happen to work by chance on the source platform and would not work in the same way, or at all, on the target platform. The sooner we detect these programs and fix them, the better. In the same way, you could consider setting the CHECK option, which enables various (other) kinds of run-time checks and allows to detect other kinds of seem-ingly-correct programs.
|
|
•
|
TRUNC: specifies whether truncation to the given PIC size occurs when assigning a value to a BINARY variable (or COMP, or COMP-4). This is similar to the TRUNC(STD) option of the IBM compiler. However, with the present specification of the ART Cobol converter, all such variables are transformed into COMP-5 variables, which do not obey the TRUNC option. See the discussion in Use of COMP-5 Type and the TRUNC Compiler Option.
|
|
•
|
APOST and QUOTE: allow to choose which character, single or double quote, the QUOTE symbolic constant will represent. This is similar to the IBM options of the same name. Use the same setting as on the source platform.
|
|
•
|
NOALTER: forbids the presence of ALTER statements in the Cobol programs. Since ALTER statements are a thing of the past, and a very bad thing at that, we recommend that you take the opportunity of migrating your asset with the ART Workbench to chase out any remaining ALTER clauses. Then, set this option to prevent their reappearance and to make compiled code more efficient and safe.
|
|
•
|
AREACHECK: Causes the Compiler to treat any token which starts in area A in the Procedure Division as a paragraph or section label, regardless of the preceding tokens. If AREACHECK is not specified, only tokens which follow a period are treated as possible labels. This directive provides closer compatibility with IBM error handling, where omitting a period before the label produces a less serious message. We recommend that such erroneous source code is corrected.
|
|
•
|
NOBYTEMODEMOVE: Controls behavior for alphanumeric moves between overlapping data items. If BYTE-MODE-MOVE is specified, data is moved one byte at a time from the source to the target. If NOBYTE-MODE-MOVE is specified, the data is moved in granules of two, four or more bytes at a time (depending on environment) from the source to the target. Consequently, if the overlap is less than the size of the granule, each granule moved overwrites part of the next granule to be moved. NO-BYTE-MODE-MOVE gives better performance, but may yield incorrect code on some very rare programs which work correctly on the source platform; we suggest that you start with the "more compatible" setting (BYTE-MODE-MOVE), perform complete regression tests until satisfaction, then choose the other option and re-test.
|
|
•
|
DYNAM: Specifies that CANCEL statements are not to be ignored. This is similar to the IBM option of the same name (but not quite the same, see the Micro Focus documentation). We strongly recommend that you set this option, because the Tuxedo servers in the ART TP Runtime system, which execute the applicative CICS programs, use CANCEL statements to free the memory used to load and run those programs. If NODYNAM is in effect, the amount of memory used by these servers would grow as they execute more and more different programs.
|
|
•
|
NOFDCLEAR, NOHOSTFD: The "positive" settings of these options reproduce the restrictions on FD usage imposed by the IBM compiler ( FD records allocated only at OPEN time, record contents lost after WRITE, etc.). We feel that these restrictions are silly and hence recommend that you don't use these options.
|
|
•
|
NOSEG: turns off segmentation and ignores all segment numbers. The resulting program is a single piece with no overlay. Who still uses segmentation, anyway?
|
|
•
|
STICKY-LINKAGE"2" / NOSTICKY-LINKAGE: this option controls how a program parameter (Linkage Section item) which has been linked to some actual data item in a previous invocation of the program may be re-linked with the same item if the current invocation specifies no new linking (no actual argument supplied). The STICKY-LINKAGE"2" setting is "more compatible" with the behavior of the source platform, especially for CICS programs, but it is certainly non-standard and error-prone. It may also be incompatible with certain features of the ART TP runtime system, in particular the possibility to distribute TP transactions over several servers running in a cluster with no shared memory. So we strongly suggest to use the default NOSTICKY-LINKAGE setting from the beginning and fix any sticky-linkage-related bugs discovered during regression testing. See also the discussion in Linkage-Section Arguments with NULL Address.
|
|
•
|
LIST: specifies the location and format of the compilation listing.
|
|
•
|
SETTINGS: specifies whether to include the complete list of compiler options in the compilation listing.
|
|
•
|
TRACE: specifies whether tracing statements (READY TRACE and RESET TRACE) are obeyed.
|
|
•
|
WARNING: specifies the verbosity of error messages printed in the compilation listing.
|
|
•
|
FLAG"dialect": specifies whether the compiler must produce language-level certification flags when it finds syntax that is not part of the specified dialect of Cobol.
|
The main behavior-influencing option to set mandatory is DIALECT"ENTCOBOL". Indeed, this dialect option sets a number of sub-options, such as
PERFORM-TYPE"ENTCOBOL", which make the target program behave as closely as possible to the original source program compiled by the IBM Enterprise Cobol Compiler.
|
•
|
NOADV: do not use special printer-control characters on text files. Target-platform printing utilities will simply print a file with the same layout as it appears on the screen.
|
|
•
|
ALIGN"8": 01- and 77-level data items are aligned at the "most universal" memory boundary.
|
|
•
|
BOUND: check that each index is between the correct bounds when accessing an array. This choice is a bit controversial because it can break some programs which apparently run correctly on the source platform. However, in our experience, the only programs which break are incorrect programs which just happen to work by chance on the source platform and would not work in the same way, if at all, on the target platform. The sooner we detect these programs and fix them, the better.
|
|
•
|
COMP-5"2": use native byte ordering for COMP-5 variables. This is necessary for compatibility with the the Rehosting Workbench CICS Runtime routines, among others.
|
|
•
|
NOCOPYLBR: copy files are just plain files, not .lbr library files.
|
|
•
|
HOSTARITHMETIC: try to comply with IBM behavior on size error conditions in arithmetic computations.
|
|
•
|
INTLEVEL"4": allow numeric variables up to 38 digits, and more generally use improved arithmetic behavior.
|
|
•
|
RWHARDPAGE: use "hard" Form Feed (FF) characters to jump to a new page in Report Writer, instead of using multiple Line Feeds. FF is recognized as jumping to a new page by all target-platform printing utilities.
|
|
•
|
NOTRUNCCALLNAME: do not truncate the names of CALLed subprograms to 8 characters, as the ENTCOBOL dialect would normally do, because the Oracle Tuxedo Application Rehosting Workbench Cobol Converter uses longer names (and this is better for future evolution anyway).
|
|
•
|
COPYEXT: specifies the file extensions used for copy files. To set according to the choices you made during migration (see the target-copy-extension configuration clause).
|
|
•
|
SETTINGS: specifies whether to include the complete list of compiler options in the compilation listing.
|
|
•
|
TRACE: specifies whether tracing statements (READY TRACE and RESET TRACE) are obeyed.
|
|
•
|
WARNING: specifies the verbosity of error messages printed in the compilation listing.
|
Specifies the location of the System Description File. As usual for Unix/Linux commands, the given path can be absolute or relative to the current working directory. Note that many other paths used by many of the Rehosting Workbench tools are then derived from the location of this file, including that of the main configuration file (see next option); this makes it easy to run the same command from different working directories.
-tce extension or -target-copy-extension extension
-cics or -activate-cics-rules
