HP 3000 Manuals HP 3000 Manuals
Conversion Issues
Most of the IBM/370 mainframe programs which you submit to this COBOL
system will be accepted syntactically and will run successfully.
However, errors may occur in a number of areas.
It is probable that you will encounter few or none of these errors, but
if you do, following the suggested solutions will greatly reduce any work
involved in migrating your application. The known errors are detailed in
the following sections together with hints on how to overcome them.
General
Error Message Differences.
The default actions or assumptions made by this COBOL system after it has
issued W or E level error messages may differ from those made by the
IBM/370 mainframe Compiler.
Solution.
You should either review all E and W level messages carefully, or modify
your source to remove the error(s).
Files not Supported.
IBM/370 BDAM
and ISAM
files and their corresponding language extensions are not supported under
this COBOL system.
Solution.
Replace any BDAM files with ANSI relative files
and any ISAM files with ANSI indexed files
.
The DISK FULL Condition.
The file status value for the DISK FULL condition under this COBOL system
is not the same as that under IBM/370 mainframe COBOL. This COBOL system
returns a hexadecimal value of X3907. An IBM/370 mainframe program
returns a character value of 30.
Solution.
Change your source program to reflect the changed value.
Arithmetic Operations.
Under IBM/370 mainframe COBOL, if you perform arithmetic operations on
nonnumeric data, it causes a program check (data exception or 0C7).
Solution.
Under this COBOL system, you must be sure the F run-time switch is set to
the default "+F".
Intermediate Result Precision.
This COBOL system uses the concept of two numeric registers designed for
worst-case calculation. This means you need 18 decimal digits (plus one
for overflow) before the decimal point for rounding capability during
MULTIPLY and DIVIDE operations. You also need 18 decimal digits (plus
one for overflow) for temporary overflow during ADD and SUBTRACT
operations. For this reason, intermediate result calculations by this
COBOL system are more accurate than in OS/VS COBOL and VS COBOL II.
Solution.
To ensure the same accuracy between these two dialects and this COBOL
system, replace any COMPUTE
statements with a series of operations using user defined intermediate
result fields. The size of each result field will vary according to the
rules documented in the OS/VS COBOL and VS COBOL II manuals.
The COMPUTE Statement.
Results of a COMPUTE statement after an OVERFLOW
condition are incompatible between the mainframe environment and this
COBOL system.
Solution.
Use the ON SIZE
...clause if there is a possibility of numeric OVERFLOW. You should never
depend on the result if this condition occurs.
PIC 9 Items.
If your source program contains PIC 9(n) DISPLAY usage
data items which contain spaces, it may fail at run time.
ACCEPT Statements.
An IBM/370 mainframe COBOL ACCEPT statement from SYSIN
is not supported by this COBOL system.
Solution.
For larger amounts of data (that is, a set of parameter cards) you should
define a new sequential file. For a single ACCEPT of a small amount of
data, enter the input data on the operating system command line when you
invoke the application, in the program use the syntax:
ACCEPT |data-name| FROM COMMAND-LINE
DISPLAY Statements.
An IBM/370 mainframe COBOL DISPLAY statement to SYSOUT
(or any other DDNAME)
is not supported by this COBOL system.
Solution.
All DISPLAYs are directed to the terminal (console). If you are using
the PC-DOS system, this allows you to redirect this output to a file if
you request it at the time the application is invoked. See your PC-DOS
Reference Manual for further details of redirection.
The SIGN SEPARATE Clause.
When you download input data from an IBM/370 mainframe which contains
signed numeric USAGE DISPLAY data items without the SIGN SEPARATE clause,
embedded signs are not interpreted correctly.
Solution.
Set the SIGN"EBCDIC"
when you submit your programs to this COBOL system. This causes this
COBOL system to output code which interprets signed data by using the
EBCDIC rather than the ASCII
convention. See your COBOL System Reference for details of this
directive.
Comparisons of Alphanumeric Data.
Comparisons of alphanumeric data under this COBOL system are not the same
as those under IBM/370 mainframe COBOL.
Solution.
Set the NATIVE"EBCDIC"
system directive when you submit your programs to this COBOL system.
This causes this COBOL system to output code which interprets signed data
by using the EBCDIC
rather than the ASCII
convention|. See your COBOL System Reference for details of this
directive.
Pointer Variables (VS COBOL II Only).
Under this COBOL system, when you redefine a VS COBOL II POINTER variable
as a COMP field, and make an arithmetical calculation on this field to
change the value of the POINTER, its behavior will not be the same as
under IBM/370 COBOL.
Solution.
The problem is because, in this COBOL system, the POINTER has a format
defined by the 8086 machine architecture, whereas the VS COBOL II POINTER
uses the 370 machine architecture.
This COBOL system provides syntax in the SET statement
which enables you to change the value of a POINTER. See your Language
Reference for details on how to do this.
File Input and Output
File Referencing.
IBM/370 mainframe COBOL programs reference data files indirectly via
DDNAMEs
. This function is not implemented in this COBOL system.
Solution.
To emulate this function, use the ASSIGN"EXTERNAL"
directive when you submit your program to this COBOL system. Before
execution, you can associate the data file-names used in your program
with physical files via the operating system SET command
.
For example, if your program contains the line:
select in-file assign to ut-s-infile.
and your data file is called C:\INFILE.DAT, you enter the command:
set infile=c:\infile.dat
which will establish the appropriate connection between the data
file-name and your application program.
The NOMINAL KEY Clause.
The mainframe COBOL NOMINAL KEY IS...clause for relative and indexed
files is not supported by this COBOL system.
Solution.
For both types of file, replace the NOMINAL KEY IS...clause with the ANSI
standard RECORD KEY IS...clause
. Also, for indexed files, you should change any Procedure Division
references to nominal key in your source programs so that they reference
record key.
The ACTUAL KEY.
and TRACK-LIMIT
Clauses
The mainframe COBOL ACTUAL KEY IS...and TRACK-LIMIT IS...clauses in
direct files are not supported by this COBOL system.
Solution.
Convert any direct files to relative files as the ACTUAL KEY IS...
clause closely resembles the RECORD KEY
clause of relative files. You can then, in most cases, delete the
TRACK-LIMIT clause.
The TRACK AREA Clause.
The TRACK AREA IS...clause for indexed files is not supported by this
COBOL system.
Solution.
You should delete this clause from your source program. TRACK AREA was
an IBM extension used to improve performance of ISAM
during | random updates. Indexed files
in this COBOL system, like mainframe VSAM files, are reorganized as they
are updated.
Deleting Records.
When you have successfully submitted your programs to this COBOL system,
you may find that on execution you cannot delete records in relative
files.
Solution.
In IBM/370 systems, you can usually delete records in relative files by
moving HIGH-VALUES to a delete byte
and rewriting the record. The ANSI standard does not require (or use) an
explicit delete byte. Therefore, you must change the syntax in your
source program so that a DELETE
operation is performed on the record.
Record Lengths.
This COBOL system checks both the minimum and maximum record lengths of a
variable length file when it is opened. The file status
is automatically set to "39" if the attributes do not match. However,
the mainframe environment only checks the maximum length value.
Solution.
Review the File Description (FD)
record descriptions to ensure that all programs referencing a variable
length file use the same minimum and maximum values.
Inter-program Communication
Calls to Subprograms.
Calls to subprograms using this COBOL system default to dynamic linkage,
whereas calls to subprograms on an IBM/370 mainframe default to static
linkage.
Solution.
Specify the NODYNAM
system directive when you submit your source program to this COBOL
system; this will cause any CALL operations to be static. See your COBOL
System Reference for further details of this directive.