HP 3000 Manuals HP 3000 Manuals
Control Options
You can put control options in any of these places:
* Control file (COBCNTL.PUB.SYS or its substitute).
* COBOL source code.
* RUN command info string.
When the source file contains nested or concatenated programs, certain
control options must appear at the beginning of the source file. If they
appear elsewhere, the compiler issues a warning and ignores them. They
need only be turned on once. The control options in this category are:
* CODE
* SYMDEBUG
* VERBS
Control options fall into the following categories:
* Performance options.
* Listing options.
* Debugging options.
* Migration options.
* Standard conformance options.
* Interprogram communication options.
* Miscellaneous options.
Performance Options
Performance options improve the performance of the compiled COBOL
program. Currently, OPTIMIZE is the only performance option. Its syntax
and effect are:
Performance Option Effect
OPTIMIZE=0 Turns off optimization. This is the default.
OPTIMIZE[=1] Turns on level one optimization.
The following lists all the possible optimization options:
If you specify: You get:
$CONTROL OPTIMIZE Level one optimization.
$CONTROL OPTIMIZE=1 Level one optimization.
$CONTROL OPTIMIZE=0 No optimization, the default.
Nothing No optimization, the default.
Although OPTFEATURES is an interprogram communication option, its
settings CALLALIGNED and LINKALIGNED are designed to improve performance.
See "Interprogram Communication Options."
Listing Options
Listing options affect the content of the compiler listing. The listing
options and their effects are:
Listing Option Effect
CROSSREF Prints a cross reference to the list file. The cross
reference lists each data and procedure name and the
lines that use them. The default is NOCROSSREF.
ERRORS=n Sets the error limit to n, an integer. The error
limit is the number of errors that the compiler can
find before it aborts the program. The default is
ERRORS=100.
LINES=n Sets the number of lines per page to n. The default
is 60 lines.
LIST Allows actual output from the control options CODE,
CROSSREF, MAP, SOURCE, and VERBS to be listed. In
included files, use LOCON instead of LIST. This is
the default. (Compare to NOLIST, LOCON and LOCOFF.)
LOCOFF Like NOLIST, except that it can be used in an
included file and can be nested. The default is
LOCON.
LOCON Like LIST, except that it can be used in an included
file and can be nested. This is the default.
MAP Prints a map of the program's variables, as offsets
from DP, SP, etc. The default is NOMAP.
MIXED Includes preprocessor commands in the compiler list
file. This is the default.
NOCROSSREF Does not print a cross reference to the list file.
This is the default.
NOLIST Turns off the control options CODE, CROSSREF, MAP,
SOURCE, and VERBS. In included files, use LOCOFF
instead of NOLIST. The default is LIST.
NOMAP Does not print a map of the program's variables.
This is the default.
NOMIXED Excludes preprocessor commands from the list file.
The default is MIXED.
NOSOURCE Does not print the source program to the list file.
The default is SOURCE.
NOVERBS Does not print a map of the offsets of the
statements. This is the default.
NOWARN Does not print warning messages to the list file.
The default is WARN.
SOURCE Prints the source program to the list file. This is
the default.
VERBS Prints a map of the offsets of the statements. The
default is NOVERBS.
WARN Prints warning messages to the list file. This is
the default.
Debugging Options
Debugging options aid in debugging. The debugging options and their
effects are:
Debugging Option Effect
BOUNDS Causes the compiler to generate code that
checks for values out of bounds at run time.
You can use this information for these
purposes:
1. To locate values that are out of
range in:
a. OCCURS DEPENDING ON identifier
statements.
b. Subscripts.
c. Indexes.
d. Reference modifications.
2. To locate illegal execution of
performed paragraphs, specifically:
a. Branches out of a performed
paragraph.
b. Indirectly recursive PERFORM
statements.
c. Performed paragraphs with
common exit points.
A limited number of the above three
situations will execute as expected
before the compiler aborts. BOUNDS
provides information that may help
you locate the problem.
3. To locate misaligned parameters.
4. To locate unaltered GO TO statements.
[REV BEG]
BOUNDS is not the default.[REV END]
CHECKSYNTAX Causes the compiler to include syntax error
messages in the compiler listing, but
prevents it from generating code. Provides
a fast way to check the syntax of your
program. This is not the default.
CODE Dumps an unformatted code listing to the
temporary file COBASSM. The default is
NOCODE.
DEBUG Enables CONTROLY trap in the executable
program, allowing program to enter MPE XL
System Debugger when the user types CONTROLY
while the program is executing. DEBUG is
for main programs only.
NOCODE Does not dump an unformatted code listing to
the file COBASSM. This is the default.
NOVALIDATE Does not check decimal and packed decimal
fields for illegal digits. This is the
default. (Compare to VALIDATE.)
SYMDEBUG Puts symbolic debug information in the
executable code. This is not the default.
Debugging Option Effect
VALIDATE Checks numeric and packed decimal operands
for illegal digits[REV BEG] and signs[REV
END] in every arithmetic operation. If an
operand is invalid, the program traps to the
trap handler, which does what the
programmer[REV BEG] specified in the
COBRUNTIME variable.[REV END] Whether the
program continues after that depends on the
value of COBRUNTIME (see "Traps" in Chapter
7 ).
VALIDATE slows execution, so you can omit it
if your program gets all its data from
computations or from other programs that
have checked its validity. VALIDATE is
essential, though, if your program gets data
from human sources (such as input from a
terminal or from a file created by a person)
and does not explicitly use class tests.
The default is NOVALIDATE.
NOTE Without the VALIDATE control option,[REV BEG] HP COBOL II/XL
sometimes treats a blank in a[REV END] DISPLAY item as if it were a
zero and does not trap blanks, but do not depend on this feature.
It is implementation dependent, not standard.
Migration Options
Migration options aid in migration (from one machine to another and from
one COBOL standard to another). The migration options and their effects
are:
Migration Option Effect
CALLINTRINSIC Causes the compiler to check all CALL statements
against the intrinsic file, SYSINTR.PUB.SYS. If the
subprogram is in the intrinsic file, but was not
called with the CALL INTRINSIC statement, the
compiler issues a warning message and generates code
to call the intrinsic.
INDEX16 Specifies 16-bit alignment for index data items.
This is the default in Compatibility Mode.
INDEX32 Specifies 32-bit alignment for index data items.
This is the default in Native Mode.
QUOTE Declares the figurative constant QUOTE (").
RLFILE Specifies that each separately compiled program in a
source file goes into its own object module in the RL
file. Programs nested within it go into the same
object module as it does. See the section "RLFILE"
for more information.
RLINIT Initializes the RL file to empty. See the section
"RLINIT" for more information.
STAT74 Causes the I-O functions to operate by the ANSI74
standard rather than the more stringent ANSI85
standard.
SYNC16 Specifies 16-bit alignment for data items that
specify SYNC. The default is 32-bit alignment
(SYNC32).
SYNC32 Explicitly specifies 32-bit alignment for data items
that specify SYNC. This is the default. (Compare to
SYNC16.)
RLFILE.
The RLFILE control option, with the RLINIT control option, simulates MPE
V object module functionality. On the MPE V operating system, programs
and subprograms are compiled into Relocatable Binary Modules, or RBMs.
RBMs are stored by compilers in USLs (User Segmented Libraries) which are
manipulated by the segmenter and the compilers. By using the COBUSL file
equation to direct compiler output into a pre-existing USL file you have
the ability to do the following:
* Compile several different programs into one USL.
* Replace a single RBM in a USL that contains multiple RBMs, by
recompiling a single program.
* Cause the USL file contents to be initialized and cleared with
every compilation, by using the USLINIT compiler option.
The RLFILE control option, with the RLINIT control option which the next
section describes, gives you on MPE XL the equivalent functionality. On
MPE XL, compiler output files are of two types:
* Native Mode Object Files. The file code is NMOBJ.
* Native Mode Relocatable Libraries. The file code is NMRL.
These file types are somewhat similar to RBMs, USLs, and RLs on MPE V.
With the RLFILE option, the compiler creates an NMRL object file. Once
main and subprograms have been compiled into this NMRL, the resulting
modules can be separately manipulated in the Link Editor or separately
replaced in subsequent compilations.
RLFILE operates at the level of the separately compiled program.
Concatenated programs (in a single source file) and programs in entirely
different source files are separately compiled programs; nested programs
are not.
When RLFILE is used, each separately compiled program has a different
name, called a module name, which is visible to the link editor. Module
names are external names (see "External Names" in Chapter 4 ).
Example 1.
This example uses an indirect file list of concatenated programs (COBSRC)
to create an NMRL.
$CONTROL RLFILE
$INCLUDE MAINP
END PROGRAM MAIN-P.
$INCLUDE SUB1
END PROGRAM SUB-1.
$INCLUDE SUB2
END PROGRAM SUB-2.
The following is the command to compile this example:
COB85XL COBSRC,COBSRCO
COBSRCO is an NMRL because the source file specified RLFILE. A LISTRL
command on COBSRCO in the Link Editor will show three separate object
modules in COBSRCO, containing the entries main_p, sub_1, and sub_2,
respectively. These object modules correspond to the three concatenated
programs in COBSRC, and they can be purged or separately manipulated in
the Link Editor.
If program SUB-1 has an error, it can be recompiled into COBSRCO with the
command:
COB85XL SUB1,COBSRCO;INFO="$CONTROL RLFILE"
As the result of this command, the module containing the object code from
program SUB-1 in COBSRCO is replaced with new object code. No other
modules in COBSRCO are changed, because COBSRCO is an NMRL. Thus it is
not necessary to recompile all the programs in COBSRC to fix one of them.
(If the object code for SUB-1 didn't exist in COBSRCO, then the new code
would be appended to COBSRCO in a new module.)
If RLFILE is not specified, whether the compiler output file is an NMRL
or an NMOBJ depends on file code of the object file (if it already
exists).[REV BEG] If the file that COBOBJ refers to[REV END] already
exists and has a file code of NMRL, the object file will be an NMRL.
However, since RLFILE was not specified, some RLFILE functionality is not
enabled. In particular, concatenated programs, when recompiled, will be
put into a single object module within the NMRL. (Recall that if RLFILE
is specified, concatenated programs are put into separate object modules
in the NMRL, allowing them to be separately manipulated in the Link
Editor.)
Example 2.
Following the example above, if both programs SUB-1 and SUB-2 have
errors, then the following indirect file list, named COBSRC1, would
compile just those two programs into the object file COBSRCO.
$INCLUDE SUB1
END PROGRAM SUB-1.
$INCLUDE SUB2
END PROGRAM SUB-2.
The following is the command to compile the above file:
COB85XL COBSRC1,COBSRCO
RLFILE is not used, but the target file COBSRCO is an NMRL. This means
that COBSRCO remains an NMRL, but the code the compiler produces for
SUB-1 and SUB-2 appears in a single object module, instead of two.
Recall that the first compilation produced an NMRL with three modules,
each containing an entry corresponding to MAIN-P, SUB-1, and SUB-2. The
second compilation results in an NMRL with two modules. The first
module, corresponding to MAIN-P, is unchanged, because the main program
was not recompiled. The second two modules, corresponding to SUB-1 and
SUB-2, become a single module, containing entries sub_1 and sub_2.
If you want to create NMRLs but don't want to edit your source to add the
RLFILE option, simply build an empty file with the code NMRL and direct
the output to this file. (This does not allow you to manipulate each
program separately in the Link Editor, however. Each compilation
produces one module, which can be manipulated.)
RLINIT.
The RLINIT control option reinitializes an NMRL object file to empty
(similar to USLINIT on MPE V). It has no effect on an NMOBJ object file.
Example.
The following example uses COBSRC1 from the previous example:
$INCLUDE SUB1
END PROGRAM SUB-1.
$INCLUDE SUB2
END PROGRAM SUB-2.
The following command compiles COBSRC1:
COB85XL COBSRC1,COBSRCO;INFO="$CONTROL RLINIT"
The effect of this step depends on the file code of COBSRCO. If COBSRCO
is an NMRL, it is reinitialized to empty before compiled code is written
to it, and it remains an NMRL. If COBSRCO is an NMOBJ, it remains an
NMOBJ. To transform COBSRCO from an NMOBJ to an NMRL, you must purge it
and compile with RLINIT or RLFILE.
Table 6-1 and Table 6-2 show how all possible combinations of
RLFILE, RLINIT, and the file type of the specified object file affect the
actual object file.
Table 6-1 applies when COBOBJ specifies an object file. The file can
be $NEWPASS, but it is $NEWPASS by specification rather than by default
(see Table 6-2 for the default case).
Table 6-1. RLFILE/RLINIT Functionally With Specified Object File
-------------------------------------------------------------------------------
| | | | |
| RLFILE | RLINIT | Specified Object File | Action |
| | | | |
-------------------------------------------------------------------------------
| | | | |
| ON | ON | Nonexistent. | Create NMRL. |
| | | Existing NMRL. | Rewrite NMRL. |
| | | Existing NMOBJ.[REV BEG] | Compile-time error. |
| | | Incorrect file code. (1) [REVmEND]-time error. |
| | | | |
-------------------------------------------------------------------------------
| | | | |
| ON | OFF | Nonexistent. | Create NMRL.[REV END] |
| | | Existing NMRL. | Compile into NMRL. |
| | | Existing NMOBJ.[REV BEG] | Compile-time error. |
| | | Incorrect file code. (1) | Compile-time error. |
| | | | |
-------------------------------------------------------------------------------
| | | | |
| OFF | ON | Nonexistent. | Create NMRL.[REV END] |
| | | Existing NMRL. | Rewrite NMRL. |
| | | Existing NMOBJ.[REV BEG] | Rewrite NMOBJ. |
| | | Incorrect file code. (1) | Compile-time error. |
| | | | |
-------------------------------------------------------------------------------
| | | | |
| OFF | OFF | Nonexistent. | Create NMOBJ.[REV END] |
| | | Existing NMRL. | Rewrite NMRL. (2) "" |
| | | Existing NMOBJ.[REV BEG] | Rewrite NMOBJ. |
| | | Incorrect file code. (1) | Compile-time error. |
| | | | |
-------------------------------------------------------------------------------
(1) The file exists, but it is not an NMRL nor an NMOBJ.
(2) In this case, not all RLFILE functionality is enabled. See example 2
in the RLFILE section.
Table 6-2 applies when[REV BEG] no file is specified for COBOBJ and
$NEWPASS is the object file.[REV END]
Table 6-2. RLFILE/RLINIT Functionally With Default File
-------------------------------------------------------------------------------
| | | | |
| RLFILE | RLINIT | Specified | Action |
| | | Object File | |
| | | | |
-------------------------------------------------------------------------------
| | | | |
| ON | ON | Nonexistent | Create NMRL. |
| | | Existing NMRL | Rewrite NMRL |
| | | Existing NMOBJ[REV BEG] | Create NMRL |
| | | Incorrect file code. (1) [REVeEND]NMRL |
| | | | |
-------------------------------------------------------------------------------
| | | | |
| ON | OFF | Nonexistent | Create NMRL[REV END] |
| | | Existing NMRL | Compile into NMRL |
| | | Existing NMOBJ[REV BEG] | Create NMRL |
| | | Incorrect file code. (1) | Create NMRL |
| | | | |
-------------------------------------------------------------------------------
| | | | |
| OFF | ON | Nonexistent | Create NMRL[REV END] |
| | | Existing NMRL | Rewrite NMRL |
| | | Existing NMOBJ[REV BEG] | Create NMRL |
| | | Incorrect file code. (1) | Create NMRL |
| | | | |
-------------------------------------------------------------------------------
| | | | |
| OFF | OFF | Nonexistent | Create NMOBJ[REV END] |
| | | Existing NMRL | Compile into NMRL |
| | | Existing NMOBJ[REV BEG] | Rewrite NMOBJ |
| | | Incorrect file type. (1) | Create NMOBJ |
| | | | |
-------------------------------------------------------------------------------
(1) The file exists, but it is not an NMRL nor an NMOBJ.
Standard Conformance Options
Standard conformance options do one of these three things:
* Cause the compiler to generate ANSI standard code in certain cases
(ANSISORT and ANSISUB).
* Cause the compiler to flag features that conform to one standard
but not another (DIFF74, STDWARN).
* Cancel another standard conformance option (NOSTDWARN).
The standard conformance options and their effects are:
Standard Conformance Option Effect
ANSISORT Allows you to open files specified in the
GIVING or USING clause of the SORT statement
in the input or output procedure of the same
SORT statement. This is not the default.
ANSISUB Maintains values of data items across calls
(as SUBPROGRAM does) and allows you to use
the CANCEL statement to reset data items to
their initial values. The default is that
the compilation unit is a main program.
DIFF74 Flags differences between the ANSI 1974 and
ANSI 1985 standards. This is not the
default.
NOSTDWARN Does not flag differences between HP COBOL
II/XL and Federal Standard COBOL features.
See also STDWARN. This option is the
default.
STDWARN Flags differences between HP COBOL II/XL and
Federal Standard COBOL[REV BEG] (that is, HP
extensions are flagged). The possible flags
are: HIGH, INT, INTSG, MIN, MINDB, and
MINSG.[REV END] Federal Standard COBOL has
three levels: HIGH, INT (intermediate), and
MIN (minimal). The default for STDWARN is
HIGH. For more information, refer to the HP
COBOL II/XL Reference Manual. The default
is NOSTDWARN.
Interprogram Communication Options
Interprogram communication options make interprogram communication
possible. The interprogram communication options and their effects are:
Interprogram Communication Option Effect
ANSISUB Maintains values of data items
across calls (as SUBPROGRAM does)
and allows you to use the CANCEL
statement to reset data items to
their initial values. The default
is that the compilation unit is a
main program.
CMCALL Specifies MPE V conventions for
converting external names. This is
not the default.
DYNAMIC Indicates a subprogram with dynamic
storage. The INITIAL clause has
the same effect. (Compare to
SUBPROGRAM and ANSISUB.)
OPTFEATURES=CALLALIGNED[16] Checks that actual parameters
in CALL statements are
word-aligned. (for CALLALIGNED)
or halfword-aligned (for
CALLALIGNED16).
OPTFEATURES=LINKALIGNED[16] Generates executable code for
formal parameters, assuming
that actual parameters are
word-aligned (for LINKALIGNED)
or halfword-aligned (for
LINKALIGNED16).
SUBPROGRAM Indicates a subprogram with its own
storage. If your program has a
LINKAGE SECTION, this is the
default; otherwise, the default is
that the compilation unit is a main
program. (Compare to DYNAMIC and
ANSISUB.)
If your source file contains nested or concatenated programs, you may
wish to turn on interprogram communication options in the middle of the
file. For example, you may want some subprograms to be ANSISUB, others
to be DYNAMIC, and the first program to be the main program.
In this situation, the following rules apply:
* If ANSISUB, DYNAMIC, or INITIAL is turned on for a program, then
it also applies to programs nested within that program.
* If ANSISUB, SUBPROGRAM, or DYNAMIC appears in the IDENTIFICATION
DIVISION of a program, then it also applies to programs nested
within that program.
* If ANSISUB, SUBPROGRAM, or DYNAMIC appears somewhere other than
the IDENTIFICATION DIVISION of a program, it applies to the next
programs in the source file.
Example.
The following shows four programs, A, B, C, and D. ANSISUB applies to
programs B and C because C is contained by B, but not to programs A and
D. The INITIAL clause in program D's IDENTIFICATION DIVISION has the same
effect and scope as DYNAMIC. In this case it only means that program D is
DYNAMIC.
Notice that IS INITIAL takes precedence over the control options.
IDENTIFICATION DIVISION.
PROGRAM-ID. A.
DATA DIVISION.
:
PROCEDURE DIVISION.
BEGIN.
:
$CONTROL ANSISUB
IDENTIFICATION DIVISION.
PROGRAM-ID. B.
:
IDENTIFICATION DIVISION.
PROGRAM-ID. C.
:
END PROGRAM C.
END PROGRAM B.
IDENTIFICATION DIVISION.
PROGRAM-ID. D IS INITIAL.
:
END PROGRAM D.
END PROGRAM A.
Miscellaneous Options
Miscellaneous options do not fit into any of the preceding option
categories. The miscellaneous options and their effects are:
Miscellaneous Effect
Option
LOCKING Allows your program to lock all files that are opened
during its execution (does not lock the files
itself). This is not the default.
USLINIT This is an HP COBOL II/V option that is[REV BEG]
ignored by HP COBOL II/XL.
NLS This option provides support for international
(multi-byte or non-ASCII) characters in certain
character operations. For a complete description,
see the appendix "MPE XL System Dependencies" in the
HP COBOL II/XL Reference Manual.
POST85 This option enables the built-in COBOL functions,
defined in 1989 by Addendum 1 of the ANSI COBOL'85
standard. For a complete description of all the
functions and how to call them, see the chapter
"COBOL Functions" in the HP COBOL II/XL Reference
Manual.[REV END]