HP 3000 Manuals HP 3000 Manuals
Manual Conversion
To successfully migrate your COBOL II/V programs to COBOL II/XL for an
MPE XL system, you should check to see if any of the changed or obsolete
features affect the programs. The obsolete and changed features are
listed in Chapter 2. The following sections explain how you need to
alter your programs given those obsolete and changed features.
Conversion of Obsolete Features
This section describes how to migrate programs from COBOL II/V to COBOL
II/XL considering obsolete features in COBOL II/XL. Topics are discussed
in the same order as outlined in Chapter 2.
1. Segment Numbers after Section Names. The MPE/V Segmenter is not
available for programs running in native mode on MPE XL systems. The
COBOL II/XL compiler ignores segment numbers after section names except
where ALTER and alterable GO TO statements exist. No performance gain is
achieved by including segment numbers after section names. Although this
requires no changes to your program, it could affect the way you write
future programs. Refer to the ^fsHP Link Editor/XL Reference Manual^s
for information on how to link COBOL II/XL programs.
2. $CONTROL Options. The following COBOL II/V $CONTROL options have no
meaning in COBOL II/XL:
ANSIPARM
BIGSTACK
SORTSPACE
USLINIT
The ANSIPARM, BIGSTACK and SORTSPACE options relate specifically to MPE V
system hardware features and do not apply to MPE XL systems. The COBOL
II/XL compiler issues a questionable error message and ignores these
options. Although it is not required, you should remove these unused
options.
The USLINIT option is accepted but performs the same function as the
RLINIT option.
3. Common Exit Points from PERFORM Statements. As specified in the 1974
and 1985 ANSI Standards, using a common point to exit from multiple
PERFORMs is illegal. In some cases on the MPE V system, however, a
program that used this construct would run without errors. Using the
$CONTROL BOUNDS option causes the compiler to generate code to see if the
paragraph stack overflows. So the easiest way to convert your programs
is to compile them with the $CONTROL BOUNDS option. The error message
does not occur until run time. If no paragraph stack overflows are
detected, you can remove the $CONTROL BOUNDS option to eliminate the
extra code that is generated.
4. Illegal GO TO Statements. As specified by the 1974 and 1985 ANSI
Standards, using GO TO statements to jump out of PERFORMed paragraphs
without returning to the paragraph is illegal. In some cases on the MPE
V system, however, a program that used this construct would run without
errors. Such a program may no longer run on the MPE XL system. You
should compile programs that may use this construct with the $CONTROL
BOUNDS option. When you run the program, if a problem is detected
concerning illegal GO TO statements out of PERFORMed paragraphs, an error
message is issued and the program aborts.
5. COBOLLOCK and COBOLUNLOCK Procedures. The COBOLLOCK and COBOLUNLOCK
procedures are available only in compatibility mode on HP 3000, Series
900 computers. (COBOLLOCK and COBOLUNLOCK were added to COBOL/68 because
the COBOL/68 compiler could not call the LOCK and UNLOCK intrinsics
directly. The COBOL II/XL extensions, the EXCLUSIVE and UN-EXCLUSIVE
statements, provide the ability to call these intrinsics directly. When
these statements were introduced, programmers were advised to replace
COBOLLOCK and COBOLUNLOCK with EXCLUSIVE and UN-EXCLUSIVE statements,
respectively.)
You have two options when converting COBOL II/V programs to COBOL II/XL.
The first and recommended option is to change all COBOLLOCK and
COBOLUNLOCK statements to EXCLUSIVE and UN-EXCLUSIVE statements. The
second option is to include a procedure that calls FLOCK and FUNLOCK in
the program.
The compiler does not indicate whether COBOLLOCK and COBOLUNLOCK are
being used. At load time, however, the loader issues an error message
that states that it could not find COBOLLOCK or COBOLUNLOCK. When you
receive this error message, you must modify the program accordingly.
6. Validation of Numeric Data Items. On MPE V systems, numeric data
items are checked for validity automatically in the microcode. On MPE XL
systems, you can explicitly check data when transferring numeric data
items. Use a de-edited MOVE when moving from an edited field to check
that no illegal characters or blanks get into a numeric field. You can
also use the NUMERIC class condition to detect invalid digits. Refer
also to the section "VALIDATE and NOVALIDATE" in Chapter 2 of this
manual. You can use these $CONTROL options to control validity checking
on MPE XL systems.
7. Calling Subprograms with CALL Identifier. In COBOL II/V, you could
use the CALL identifier statement to call a subprogram using the
subprogram "plabel." This feature is not supported in COBOL II/XL. The
COBOL II/XL compiler issues an error message when it encounters a CALL
identifier statement with a numeric identifier. You must change the CALL
statement to call the appropriate subprogram by its name instead of using
plabel. The CALL identifier statement may also be changed to a CALL
literal statement wherever possible.
8. Calling Intrinsics with CALL Identifier. The CALL identifier
statement cannot be used to call an intrinsic, with the exception of
VPLUS/TurboImage CALLS. Change the CALL identifier statement to one or
more conditionally executed CALL INTRINSIC literal statements instead.
Conversion of Changed Features
This section describes how to convert programs from COBOL II/V to COBOL
II/XL considering the features that have changed. Topics are discussed
in the same order as listed in "Changed Features" in Chapter 2.
1. INDEX Data Items. INDEX data items are data items that have the
USAGE IS INDEX clause. Index names appear in the INDEXED BY phrase of
the OCCURS clause in the declaration of tables. The following change
affects only INDEX data items, not index names.
INDEX data items are 16 bits on MPE V systems and 32 bits on MPE XL
systems. INDEX data items within a record change the byte offset of all
following data items in the record. Any record that redefines this
record (in a REDEFINES clause) is also affected. This will only cause a
problem in your program when reading a record created on an MPE V system
that contains an INDEX data item embedded in it. In this case, the index
value is invalid and all the data following it in the record will be
skewed. (You must modify the REDEFINEd items to correct this problem.)
A new $CONTROL option, INDEX16, causes 16 bits of storage to be allocated
for each INDEX data item following the option. If your program reads
records that have 16-bit INDEX data items embedded in them, you should
include this $CONTROL option so the information in the file will be read
correctly. Note, however, that the contents of the INDEX data items are
invalid and using them produces unpredictable results. The INDEX16
option merely allows you to access the data remaining in the record.
Including the INDEX32 option after the record that is being read from a
file allocates 32 bits of storage for INDEX data items again.
You must include the INDEX16 and INDEX32 options in the program before
the 01 level of the record and not within a record. You can also place
the INDEX16 option in the COBCNTL file to make it the system default.
Refer to Chapter 4 for information on how to convert data files that
contain INDEX data items.
2. Synchronized Data Items. All level 01, 77 and SYNCHRONIZED data
items are aligned on 16-bit boundaries on MPE V systems, by default. On
MPE XL systems, the default data alignment varies according to the
position of the data item in the source program. In the WORKING-STORAGE
and FILE sections, level 01, 77, COMP or BINARY SYNCHRONIZED data items
and INDEX data items are aligned on 32-bit boundaries. In the LINKAGE
section, all data items are aligned on 8-bit (byte) boundaries even if
the SYNCHRONIZED clause is specified.
The potential problem here concerns data items that are aligned in a
record using the SYNCHRONIZED clause. The SYNCHRONIZED clause specifies
that the data described is to be aligned on 32-bit boundaries. If the
SYNCHRONIZED item does not fall naturally on a 32-bit boundary, the
compiler assigns the next highest boundary address to the item, thus
creating extra filler characters known as slack bytes just before the
item. (Refer to the HP COBOL II Reference Manual for more information on
slack bytes.) Any record that redefines this record may also be
affected.
Because of the difference in alignment, the number of slack bytes on MPE
V and MPE XL systems can differ for a given record. Like INDEX data
items, this could affect the position of data items following the
SYNCHRONIZED data items and would cause data read from a file to be
skewed.
Several $CONTROL options are available to change data alignment: SYNC16,
LINKALIGNED and LINKALIGNED16. However, these options only affect data
items in particular portions of the source program.
Specifying $CONTROL SYNC16 affects the WORKING-STORAGE, FILE and LINKAGE
sections differently. Within the WORKING-STORAGE and FILE sections,
level 01 and 77 items are aligned on 32-bit boundaries; COMP or BINARY
SYNCHRONIZED data items and INDEX data items are aligned on 16-bit
boundaries. Specifying $CONTROL SYNC16 affects the LINKAGE section by
causing each COMP or BINARY SYNCHRONIZED data item and INDEX data item to
be aligned on a 16-bit boundary from the start of the 01 record.
Specifying $CONTROL OPTFEATURES=LINKALIGNED affects only the LINKAGE
section. Within the LINKAGE section, level 01 and 77 items are assumed
to be aligned on 32-bit boundaries.
Specifying $CONTROL OPTFEATURES=LINKALIGNED16 also affects only the
LINKAGE section. Within the LINKAGE section, level 01 and 77 items are
assumed to be aligned on 16-bit boundaries.
The SYNC16 option allows SYNCHRONIZED data items and INDEX data items to
be aligned on 16-bit boundaries starting with the record following the
option. SYNC32 returns alignment to 32-bit boundaries. You can change
the default to SYNC16 by putting the option in the COBCNTL file.
Alternatively, you can include the option immediately before each record
declaration. The option remains in effect until another SYNC16 or SYNC32
option is encountered in the program. Refer to Chapter 4 for information
on how to convert data files that contain SYNCHRONIZED data items.
NOTE If you used SYNC32 to create the data file on an MPE V system, no
programming changes are required for MPE XL. The SYNCHRONIZED data
items have the same alignment and the records have the same byte
offsets on both machines.
3. $CONTROL MAP, $CONTROL CODE and $CONTROL VERBS Options. The format
and content of the information generated by the $CONTROL MAP, $CONTROL
CODE, and $CONTROL VERBS options differ on MPE XL systems from the way
they work on MPE V systems. This should not affect any programs. The
information generated by these options may not be required now because of
the availability of symbolic debuggers on MPE XL systems.
For small programs, the $CONTROL VERBS option gives the byte offset of
each statement from the beginning of the program. Large programs are
broken into "chunks." Thus for large programs, this option gives the byte
offset of each statement from the beginning of each chunk.
Because the locations of data are expressed in architecture-dependent
terminology, the $CONTROL MAP option provides different information on
MPE V and MPE XL systems.
If you specify the $CONTROL CODE option, an assembly language listing is
written to the temporary file COBASSM. The assembly languages are
different for MPE V and MPE XL systems.
Refer to the HP COBOL II/XL Programmer's Guide for more information on
these $CONTROL options.
4. Hyphen Conversion in External Names. The COBOL II/V compiler removes
hyphens within the external names used in the CALL statement, the ENTRY
statement and the PROGRAM-ID paragraph. The COBOL II/XL compiler
converts the hyphens to underscores.
The only programs that will require a change are those which depend on
the removal of the hyphen for the program to work. In this case, you
must change one of the names to match the other. Although this will not
cause an error when you compile and link the program, the loader will
fail. It issues an error message stating that the entry point specified
on the CALL statement could not be found. You should look at the
external name that is undefined and identify all CALLs to that subprogram
to check that the names match the corresponding ENTRY statement or
PROGRAM-ID paragraph.
You can also use the $CONTROL CMCALL option to strip hyphens from
external names instead of converting them to underscores. Refer to the
section "CMCALL" in Chapter 2.
5. External Name Length. External names are those literals appearing in
the PROGRAM-ID paragraph and the ENTRY and CALL statements. The COBOL
II/V compiler truncates external names after the first 12 (main programs)
or 15 (subprograms) characters. The COBOL II/XL compiler truncates them
after the first 30 characters.
The only programs that will be affected by this change are those which
depend on name truncation after 15 characters. That is, the program uses
external names that are the same for the first 15 characters, then the
names vary in some way. In this case, you should change one of the names
to match the other. Although changing names will not cause an error when
you compile and link the program, the loader will fail. It issues an
error message stating that it could not find the entry point specified on
the CALL statement. You should check the external name that is undefined
and locate all calls to that subprogram to check that the names match the
ENTRY statement or PROGRAM-ID paragraph with that name.
You can also use the $CONTROL CMCALL option to truncate external names to
15 characters instead of 30 characters. Refer to the section "CMCALL" in
Chapter 2.
6. Case of External Names. External names are literals appearing in the
ENTRY and CALL statements and the ^fsprogram-name^s in the PROGRAM-ID
paragraph. Two external names that differ only in case are considered
unique on the MPE V system, but are no longer unique on the MPE XL
system. The COBOL II/XL compiler converts all external names to
lowercase, regardless of how they appear in your program. Therefore, you
must change any external names that vary only in case. The compiler does
not detect the error. At run time, the loader issues an error message
stating that an entry point is doubly defined.
If you must preserve the case of names, precede the names with a
backslash. This instructs the compiler not to convert the name to
lowercase. However, this introduces case dependency to the program.
7. Address Length. Addresses on MPE XL systems are 32 bits or 64 bits
whereas addresses on MPE V systems are 16 bits. The GIVING identifier in
the .LOC. pseudo-intrinsic is used to hold an address and must therefore
be defined as PIC S9(4) COMP SYNC on MPE V systems and PIC S9(9) COMP
SYNC for a 32-bit address or PIC S9(18) COMP SYNC for a 64-bit address on
MPE XL systems. The one you use will depend on what the address is used
for. The COBOL II/XL compiler issues an error message if you do not
change the GIVING identifier definition.
8. Command Files for COBOL II/XL. The COBOL II/XL compile commands are
different under MPE XL but the compile parameters are identical. The new
compile commands are listed below. The COB85XL and COB74XL commands let
you create an objectfile that can be either a relocatable object file or
a relocatable library. If you use the RLFILE or RLINIT option of the
$CONTROL command, the objectfile is a relocatable library. If you omit
the RLFILE and RLINIT options, the objectfile is a relocatable object
file consisting of one object module. Subsequent compilations that use
the same relocatable object file, overwrite it. To avoid this overwrite,
use a different objectfile name for each compile. See the HP Link
Editor/XL Reference Manual for information on how to link relocatable
object modules.
The COBOL II/XL compile commands follow. The parameters for each command
are optional. If you omit one, enter a comma for it (you do not need to
enter commas at the end of the command line).
COB85XL [textfile] [,objectfile] [,listfile] [,masterfile]
[,newfile] [;INFO="info"] [;WKSP=workspacename]
invokes the COBOL II/XL (native mode) compiler, using the 1985 ANSI
standard-conforming entry point and creates an object file.
COB85XLK [textfile] [,progfile] [,listfile] [,masterfile]
[,newfile] [INFO="info"] [;WKSP=workspacename]
invokes the COBOL II/XL (native mode) compiler, using the 1985 ANSI
standard-conforming entry point. It also links the object file and
creates a program file.
COB85XLG [textfile] [,listfile] [,masterfile]
[,newfile] [;INFO="info"] [;WKSP=workspacename]
invokes the COBOL II/XL (native mode) compiler, using the 1985 ANSI
standard-conforming entry point. It creates and runs a program file in
$OLDPASS.
COB74XL [textfile] [,objectfile] [,listfile] [,masterfile]
[,newfile] [;INFO="info"] [;wksp=workspacename]
invokes the COBOL II/XL (native mode) compiler, using the 1974 ANSI
standard-conforming entry point and creates an object file.
COB74XLK [textfile] [,progfile] [,listfile] [,masterfile]
[,newfile] [;INFO="info"] [;WKSP=workspacename]
invokes the COBOL II/XL (native mode) compiler, using the 1974 ANSI
standard-conforming entry point. It also links the object file and
creates a program file.
COB74XLG [textfile] [,listfile] [,masterfile] [,newfile]
[;INFO="info"] [;WKSP=workspacename]
invokes the COBOL II/XL (native mode) compiler, using the 1974 ANSI
standard-conforming entry point. It creates and runs a program file in
$OLDPASS.
You must remember to examine all job files containing COBOL or COBOL II
commands and change them to the appropriate command. You can also use
the RUN command as you would on MPE V; however, the COBUSL formal file
designator is COBOBJ for COBOL II/XL. Two entry points are available when
using the RUN command. The default entry point is the 1985 ANSI
standard. To run COBOL for the 1985 ANSI standard, you should use the
following command:
RUN COBOL.PUB.SYS, ANSI85;PARM=1
To run COBOL for the 1974 ANSI standard use the command:
RUN COBOL.PUB.SYS, ANSI74;PARM=1
The RUN command can be placed in user-defined command files to customize
the command to your needs. Refer to the HP COBOL II/XL Reference Manual
Supplement for more information on the RUN command.
9. Calls to System Intrinsics. The COBOL II compiler handles calls to
intrinsics by looking in the intrinsic file for information about how to
generate the call properly. Some interfaces to intrinsics on MPE XL have
changed from the corresponding ones in MPE V. To be sure that all
intrinsic calls are correct, include the word INTRINSIC in all intrinsic
calls (except for IMAGE, VPLUS and KSAM intrinsics). Excluding the CALL
INTRINSIC statement can generate incorrect code and produce unexpected
results.
For example, if you call FOPEN, FCLOSE, FREAD, or FWRITE without using
the CALL INTRINSIC form of the CALL statement, the compiler interprets
these as calls to your own subprograms called fopen, fclose, fread and
fwrite, respectively. If you do not have subprograms with these names
and you really intended to call the MPE XL intrinsics, your program could
get linked to routines with the same names in the C run-time library.
The compiler produces no error message in this case. But because the
calling sequences for C routines and the MPE XL intrinsics are different,
the results of executing these calls are unpredictable. A run-time error
may occur. If so, it will probably be a data memory protection trap.
Therefore, you should always use CALL INTRINSIC when calling any MPE XL
system intrinsic.
You can use a new $CONTROL option CALLINTRINSIC to assist in migrating
intrinsic calls. When you specify this option, the COBOL II compiler
checks the intrinsic file at every CALL statement. If the specified
subprogram is found in the intrinsic file, a warning message is given and
code is generated to call that intrinsic. You should check all CALL
statements that generate the message and insert the CALL INTRINSIC
statement where appropriate. The $CONTROL CALLINTRINSIC option is
intended only as a migration aid; remove it when all CALL statements are
checked and modified as needed.
In addition, some intrinsics are specific to MPE V and will not be
available on MPE XL or will perform no action in native mode on MPE XL.
The COBOL II compiler provides error messages for intrinsics it does not
locate. You should remove calls to these intrinsics when migrating your
programs.
10. References To Table Elements. The performance when referencing
table elements using subscripts defined as
PIC S9(9) COMP SYNC
is the same as referencing table elements using INDEX data items in COBOL
II/XL. No program changes are required.
11. Validity Checking. Validity checking of ASCII and decimal digits on
MPE V systems is done in the microcode; on MPE XL systems, validity
checking must take place in the software. This affects program
performance. Because the COBOL language provides a means for checking
data, you may not require additional validity checking. In COBOL II/XL,
you can indicate whether or not you want validity checking to be done.
The default when compiling programs is to perform no validity checking.
You must specify a $CONTROL option to induce a validity check. Refer to
"VALIDATE and NOVALIDATE" in Chapter 2.
On MPE V systems, numeric DISPLAY and PACKED-DECIMAL data are checked for
validity, by default. On MPE XL systems, no validity checking of this
data takes place, by default. HP COBOL II/XL programs cannot be expected
to execute the same way with illegal or incompatible data values, that
is, when the value of a data item does not match its picture clause. The
following is a list of known differences in execution:
* Invalid digits
* MPE V program - When a numeric data item containing invalid ASCII
digits is moved to another numeric item, an error message is
printed and the compiler attempts to correct the target of the
MOVE statement. The program continues to execute.
* MPE XL program (compiled without $CONTROL VALIDATE) - Illegal
ASCII or decimal digits are propagated in a move from one data
item to another. Computations using a value with illegal ASCII
or decimal digits will have unpredictable results.
* MPE XL program (compiled with $CONTROL VALIDATE) - The invalid
digit is detected. The action taken depends on the value of the
job/session level variable COBRUNTIME. Refer to the section
"Error Handling Options" in Chapter 2 for more information.
To make an MPE XL COBOL program behave like an MPE V program, compile the
program with the $CONTROL VALIDATE option and set the invalid
ASCII/decimal digit character position of COBRUNTIME to either M or N.
Note that this does not recreate the exact behavior. On MPE V systems,
only the target of the MOVE is corrected. On MPE XL systems (assuming
$CONTROL VALIDATE was used and COBRUNTIME contains M or N), when the
invalid character is detected in the sending field, a valid digit will be
placed in the target, but the source location may also be overwritten by
the valid digit.
* Illegal Leading Blanks
* MPE V program - When a numeric data item containing illegal
leading blanks is moved to another numeric item, no error message
is printed. But, the leading blanks are converted to zeros
before being put into the receiving item. The leading blanks in
the sending item are not changed. The program continues to
execute.
* MPE XL program (compiled without $CONTROL VALIDATE) - Leading
blanks in data items that are defined as numeric are not
converted to zeros after a MOVE of the value from one item to
another. Calculations using these data items will work as
expected. If you MOVE the numeric field (that has leading
blanks) to a numeric edited field, zero suppression and floating
dollar sign insertion will fail.
* MPE XL program (compiled with $CONTROL VALIDATE) - The illegal
leading blanks are detected. The action taken depends on the
value of the job/session level variable COBRUNTIME. Refer to the
section "Error Handling Options" in Chapter 2 for more
information.
To make an MPE XL COBOL program behave like an MPE V program, compile the
program with the $CONTROL VALIDATE option and specify N in the character
position of COBRUNTIME that corresponds to the one containing the illegal
ASCII/decimal digit (character position 1 or 8 in Table 2-2).
Note that this does not recreate the exact behavior of the MPE V program.
On MPE V systems, only the leading blanks in the target of the MOVE are
changed to zeros.
On MPE XL systems (assuming $CONTROL VALIDATE was used and COBRUNTIME
contains M or N), the leading blanks in the source of the MOVE statement
may also be replaced by zeros.
* Signed Data Items with Unsigned Values
* MPE V program - Unsigned values in DISPLAY or PACKED-DECIMAL data
items described as signed will have a plus sign (+) overpunched
or added after a MOVE from one data item to another. No error
message is given and the program continues to execute.
* MPE XL program (compiled without $CONTROL VALIDATE) - Unsigned
values in data items described as signed may not have a sign
added after a MOVE from one data item to another. Calculations
using these data items will work as expected.
* MPE XL program (compiled with $CONTROL VALIDATE) - The unsigned
value is detected. The action taken depends on the value of the
job/session level variable COBRUNTIME. Refer to the section
"Error Handling Options" in Chapter 2 for more information.
To make an MPE XL COBOL program behave like an MPE V program that uses
DISPLAY or PACKED-DECIMAL data, compile the program with the $CONTROL
VALIDATE option and specify N in the character position of COBRUNTIME
that corresponds to that of the invalid ASCII/decimal digit (character
position 1 or 8 in Table 2-2). A plus sign will be overpunched or added
in the described case.
* Unsigned Data Item with Signed Value
* MPE V program - A negative value in a data item described as
unsigned will not be modified when moved to a signed data item.
* MPE XL program (compiled without $CONTROL VALIDATE) - A negative
value in a data item described as unsigned will have a positive
value after a MOVE to a signed data item.
* MPE XL program (compiled with $CONTROL VALIDATE) - A negative
value is detected. The action taken depends on the value of the
job/session level variable COBRUNTIME. Refer to the section
"Error Handling Options" in Chapter 2 for more information.
To make an MPE XL COBOL program behave like an MPE V program, compile the
program using the $CONTROL VALIDATE option and specify N in the character
position of COBRUNTIME that corresponds to the illegal ASCII
decimal/digit (character position 1 or 8 in Table 2-2). The minus sign
is not changed in this case.
* COMP-3 Data Items with an Even Number of Digits
* MPE V program - The contents of the high-order nibble of a USAGE
COMP-3 data item with an even number of digits does not affect
calculations on the data item.
* MPE XL program (compiled without $CONTROL VALIDATE) - If the
high-order nibble of a USAGE COMP-3 data item with an even number
of digits has a nonzero value, the result of computations using
this data item are unpredictable. (A nibble is a half byte.)
This is only a problem with files created on non-HP machines.
* MPE XL program (compiled with $CONTROL VALIDATE) - If the
high-order nibble is not valid, a trap occurs. If the nibble is
valid, this is the same as $CONTROL NOVALIDATE.
In the first case above, you must strip the bad nibble from data fields
having an even number of digits. For example, the following field
BAD-COMP-3-ITEM must be converted so that it can be processed without
error:
01 REC.
05 FILLER PIC X(10).
05 BAD-COMP-3-ITEM PIC S9(6) COMP-3.
The following code shows how to convert BAD-COMP-3-ITEM. BAD-COMP-3-ITEM
is redefined with an additional digit. This redefined field is moved to
NEW-COMP-3-ITEM, which is a temporary field defined with the same number
of digits as the original field. Finally, NEW-COMP-3-ITEM is moved back
to the original field, BAD-COMP-3-ITEM.
77 NEW-COMP-3-ITEM PIC S9(6) COMP-3.
01 REC.
05 FILLER PIC X(10).
05 BAD-COMP-3-ITEM PIC S9(6) COMP-3.
05 BAD-COMP-3-ITEM-R REDEFINES BAD-COMP-3-ITEM
PIC S9(7) COMP-3.
.
.
.
MOVE BAD-COMP-3-ITEM-R TO NEW-COMP-3-ITEM.
MOVE NEW-COMP-3-ITEM TO BAD-COMP-3-ITEM.^s
* Blank in Separate Sign Position
* MPE V program - A blank in the SEPARATE SIGN position generates a
signed data value in a MOVE to a signed data item with no
SEPARATE SIGN clause.
* MPE XL program (compiled without $CONTROL VALIDATE) - A blank in
the SEPARATE SIGN position generates an unsigned data value or
blanks in a MOVE to a signed data item with no SEPARATE SIGN
clause.
* MPE XL program (compiled with $CONTROL VALIDATE) - $CONTROL
VALIDATE had no effect in this case.
To make an MPE XL COBOL program behave like an MPE V program, change the
code so that it checks for a blank in the separate sign position and
moves a plus sign (+) character into that position. You can use
reference modification to isolate that position of the identifier or use
the REDEFINES clause. For example,
01 REC.
05 FILLER PIC X(10).
05 BAD-ITEM PIC S9(5)V99 SIGN TRAILING SEPARATE.
Using reference modification:
IF BAD-ITEM(8:1) = SPACE
MOVE "+" TO BAD-ITEM(8:1).
12. Program Aborts. If a program aborts with an ILLEGAL ASCII DIGIT
error, use a numeric class test. If a program aborts with a DIVIDE BY
ZERO or OVERFLOW error, include an ON SIZE ERROR clause in the program.
13. 32-Bit BINARY and COMPUTATIONAL Data Items. Thirty-two bit BINARY
and COMPUTATIONAL data items that are part of a record and do not have
the SYNC clause may not be aligned on a 16-bit or 32-bit boundary. If a
misaligned data item is passed to a subprogram or an intrinsic that
expects the data item to be aligned, an error results.
There are three cases in which data might be misaligned:
1. Calling a COBOL II subprogram: You may only encounter problems if
you specify the CALLALIGNED/16 and LINKALIGNED/16 options. The
compiler expects parameters to be aligned if you specify these
options and issues error messages for parameters that are not on
proper boundaries. To correct the errors, add SYNC to the data
item descriptions specified in the error messages, or add FILLER
items to the record description or move the data item to an 01 or
77 level item. Simply removing the CALLALIGNED/16 and
LINKALIGNED/16 options also corrects the errors but results in
less efficient code.
2. Calling an intrinsic: If an intrinsic requires a parameter to be
aligned on a 32-bit boundary and the actual parameter is not
aligned, the compiler issues an error message stating that it is
not aligned on the proper boundary. To fix the problem, add SYNC
to the data item description, or add FILLER items to the record
description or move the data item to an 01 or 77 level item.
3. Calling a non-COBOL II subprogram: Subprograms written in other
languages may require parameters to be aligned. If you specify
the CALLALIGNED or CALLALIGNED16 options, the compiler issues an
error message for any parameter that is misaligned. Correct the
errors by adding SYNC to the data descriptions of the misaligned
options, or add FILLER items to the record description or move the
data item to an 01 or 77 level item. If you do not use the
CALLALIGNED/16 option, the compiler issues no error message.
However, when appropriate link options are used, the linker issues
errors for any misaligned parameters. Again, you should add SYNC
to the data descriptions of these parameters or add FILLER items
to the record description or move the data item to an 01 or 77
level item.
NOTE You can temporarily specify the CALLALIGNED or CALLALIGNED16 option
to check all calls to non-COBOL II subprograms. After aligning any
misaligned parameters passed to non-COBOL II subprograms (as
described above), you can remove the CALLALIGNED/16 option.
14. Trap on Integer Overflow. When adding two items defined as S9(18)
or S9(9) COMP (or BINARY) COBOL II/XL may trap with integer overflow if
the result is greater than approximately 2*10**18 or 2*10**9,
respectively, unless an ON SIZE ERROR clause is included. After a trap,
the integer result is unpredictable. COBOL II/V truncates the digits and
no trap occurs. You should include the ON SIZE ERROR clause when
performing addition where both operands are defined as S9(18) or S9(9)
COMP (or BINARY) and you are working with very large numbers. Refer to
"Error Handling Options" in Chapter 2 for more information on run-time
traps and controlling the response to particular error conditions.
15. @ Parameters. On MPE V systems, the commercial at sign (@)
preceding a parameter in the USING phrase of the CALL statement indicates
that the byte address of that parameter should be passed to the
subprogram being called. Because all addresses are byte addresses on MPE
XL systems, the @ is ignored.
16. Uninitialized Data Items. Data items that have not been initialized
in your program contain unknown contents and, therefore, will produce
unpredictable results. The contents of uninitialized data items may
differ between MPE V and MPE XL. Consequently, COBOL programs that run
without errors on MPE V may have errors when run on MPE XL systems.
Refer to Chapter 10, "Interprogram Communication" in the HP COBOL II
Reference Manual for information about the initial state of a program.
NOTE You MUST initialize all data items before using them.
17. Truncation of BINARY and COMPUTATIONAL Results. The way arithmetic
results are truncated for BINARY and COMPUTATIONAL items is different on
MPE XL systems. Because of this, compare operations that use truncated
results may not produce the same results.
On MPE V systems, a data item containing a USAGE IS COMP (or BINARY)
clause is truncated (if necessary) on a decimal digit boundary. On MPE
XL systems, the data item is truncated on a 16 or 32-bit boundary.
If your MPE V program depends on this truncation for its compare
operations to work, you should make one of the following changes:
1. Add the ON SIZE ERROR clause to the arithmetic operation that
produces the result, then handle the size error in the program.
This is the recommended action because it is the ANSI standard.
According to the standard, if an ON SIZE ERROR clause is not used
and a size error occurs, results are unpredictable. If the ON
SIZE ERROR clause is used, the previous value in the result field
is preserved. See the "Error Handling Options" in Chapter 2 for
ways to handle ON SIZE ERROR run-time errors.
There is an instance in which the use of ON SIZE ERROR does not
handle the truncation problem discussed in the previous
paragraph. If a field is defined as a S9(18) COMP field and
contains more than 18 digits, move the field to a S9(18) COMP-3
field defined before the arithmetic operation. This produces
the same results as MPE V produces when it truncates after the
arithmetic operation.
2. Increase the size of the result field to handle the largest
possible result, so that no truncation will occur. Then, use the
MOVE statement to truncate the result, if necessary.
3. Change the USAGE IS BINARY or COMPUTATIONAL clause to USAGE IS
DISPLAY or COMP-3.