COBOL Set For AIX Programming Guide
COBOL Set For AIX Programming Guide
Programming Guide
Release 1
SC26-8423-03
COBOL Set for AIX IBM
Programming Guide
Release 1
SC26-8423-03
Note!
Before using this information and the product it supports, be sure to read the general infor-
mation under “Notices” on page xvii.
This edition applies to Version 1, Release 1, Modification 1 of IBM COBOL Set for AIX (program number 5765-548)
and to all subsequent releases and modifications until otherwise indicated in new editions.
Order publications through your IBM representative or the IBM branch office serving your locality. Publications are not
stocked at the address given below.
A form for reader's comments appears at the back of this publication. If the form has been removed, address your
comments to:
IBM Corporation, W92/H3
P.O. Box 49023
San Jose, CA 95161-9023
U.S.A.
When you send information to IBM, you grant IBM a non-exclusive right to use or distribute the information in any way
it believes appropriate without incurring any obligation to you.
Copyright International Business Machines Corporation 1996, 1998. All rights reserved.
Note to U.S. Government Users — Documentation related to restricted rights — Use, duplication or disclosure is
subject to restrictions set forth in GSA ADP Schedule Contract with IBM Corp.
Contents
Notices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvii
Programming Interface Information . . . . . . . . . . . . . . . . . . . . . . . . . xvii
Trademarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xviii
Contents v
Evaluating Single Characters for Collating Sequence (CHAR, ORD) . . . . . . 86
Finding the Largest or Smallest Data Item (MAX, MIN, ORD-MAX, ORD-MIN) 86
Finding the Length of Data Items (LENGTH) . . . . . . . . . . . . . . . . . . 88
Finding the Date of Compilation (WHEN-COMPILED) . . . . . . . . . . . . . 88
Contents vii
SOURCE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
SPACE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
SPILL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
SQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
SSRANGE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
TERMINAL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
TEST . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179
THREAD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179
TRUNC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
TYPECHK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
VBREF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184
WORD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184
| WSCLEAR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
XREF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
| YEARWINDOW . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186
ZWB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
Compiler-Directing Statements . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
Contents ix
Changes to Class or Subclass Definitions . . . . . . . . . . . . . . . . . . . 261
Changes to the Client Program . . . . . . . . . . . . . . . . . . . . . . . . . 261
Complete Metaclass with Methods Example . . . . . . . . . . . . . . . . . . . . 262
Contents xi
Sharing Files between Programs (EXTERNAL Files) . . . . . . . . . . . . . . . 346
Advantages of EXTERNAL Files . . . . . . . . . . . . . . . . . . . . . . . . 346
Example Using EXTERNAL Files . . . . . . . . . . . . . . . . . . . . . . . . 347
Command Line Arguments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 351
Without -host Option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 351
With -host Option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 352
Contents xiii
Simplifying Complex Coding and Other Programming Tasks . . . . . . . . . . . 422
Intrinsic Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 422
Date and Time Callable Services . . . . . . . . . . . . . . . . . . . . . . . . 422
Optimization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 431
The OPTIMIZE Compiler Option . . . . . . . . . . . . . . . . . . . . . . . . 432
Other Compiler Features that Affect Optimization . . . . . . . . . . . . . . . 433
Compiler Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 433
Bibliography . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 562
COBOL Set for AIX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 562
Related Publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 562
COBOL for OS/390 & VM . . . . . . . . . . . . . . . . . . . . . . . . . . . . 562
Contents xv
VisualAge COBOL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 562
CICS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 562
DB2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 562
SMARTdata Utilities for AIX . . . . . . . . . . . . . . . . . . . . . . . . . . . 562
SOMobjects for AIX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 562
Other . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 562
Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 563
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 586
IBM may have patents or pending patent applications covering subject matter in this
document. The furnishing of this document does not give you any license to these
patents. You can send license inquiries, in writing, to the IBM Director of Licensing,
IBM Corporation, 500 Columbus Avenue, Thornwood, NY 10594, U.S.A.
Licensees of this program who wish to have information about it for the purpose of
enabling: (1) the exchange of information between independently created programs and
other programs (including this one) and (2) the mutual use of the information which has
been exchanged, should contact:
General-Use programming interfaces allow the customer to write programs that obtain
the services of IBM COBOL Set for AIX.
AD/Cycle IBM
AIX IMS
AIX/6000 Language Environment
C/370 OS/2
CICS OS/390
CICS OS/2 RS/6000
COBOL/370 System Object Model
DATABASE 2 System/390
DB2 SOMobjects
DFSMS/MVS System/370
DFSORT VisualAge
UNIX is a registered trademark in the United States and other countries licensed exclu-
sively through X/Open Company Limited.
Microsoft, Windows, Windows NT, the Windows 95 logo, and Open Database
Connectivity are trademarks or registered trademarks of Microsoft Corporation.
Other company, product, and service names, which may be denoted by a double
asterisk (**), may be trademarks or service marks of others.
IBM COBOL Set for AIX supports local and remote access to DB2, CICS, and VSAM,
giving you access to data and transactions nearly anywhere in your enterprise. And all
the IBM COBOL family of solutions support high subset ANSI 85 COBOL functions, so
your applications can be ported across supported platforms, whether they are running
on a mainframe, an RS/6000, or a personal computer with OS/2.
IBM COBOL Set for AIX supports object-oriented extensions, allowing you to move your
applications to object-orientation at the level and pace you desire.
IBM COBOL Set for AIX provides an integrated development environment, with easy
access to visual tools and project file management. IBM COBOL Set for AIX is fully
integrated with the new industry-standard UNIX** interface specification, the Common
Desktop Environment (CDE). CDE integrates your tools and files, so selecting a file
also selects the application you need to control the execution of a program, examine
and modify data, and perform many other useful functions. Integrated within the
Common Desktop Environment are visual tools that will help you create, edit, debug,
and manage your applications.
This book assumes experience in developing application programs and some know-
ledge of COBOL. It focuses on using COBOL to meet your programming objectives
and not on the definition of the COBOL language. For complete information on COBOL
syntax, refer to IBM COBOL Language Reference.
There are some differences between host and workstation COBOL. For details on lan-
guage and system differences between IBM COBOL Set for AIX and IBM COBOL for
OS/390 & VM, see Appendix A, “Summary of Differences with Host COBOL” on
page 466.
This book also assumes familiarity with AIX and the IBM COBOL Set for AIX develop-
ment environment. For information on AIX, see your operating system documentation.
To learn about the IBM COBOL Set for AIX development environment, see the Getting
Started guide.
Abbreviated Terms
Certain terms are used in a shortened form in this book. Abbreviations for the product
names used most frequently in this book are listed alphabetically in Figure 1. Abbrevi-
ations for other terms, if not commonly understood, are shown in italics the first time
they appear, and are listed in the glossary in the back of this book.
In addition to these abbreviated terms, the term “COBOL 85 Standard” is used in this
book to refer to the combination of the following standards:
ISO 1989:1985, Programming languages - COBOL
ISO 1989/Amendment 1, Programming Languages - COBOL - Amendment 1:
Intrinsic function module
X3.23-1985, American National Standard for Information Systems - Programming
Language - COBOL
X3.23a-1989, American National Standard for Information Systems - Programming
Language - Intrinsic Function Module for COBOL
The two ISO standards are identical to the American National standards.
Syntax Notation
Throughout this book, syntax for the compiler options is described using the structure
defined below.
Read the syntax diagrams from left to right, from top to bottom, following the path
of the line. The following table shows the meaning of symbols at the beginning
and end of syntax diagram lines.
Symbol Indicates
55─── The syntax diagram starts here
───5 The syntax diagram is continued on the next line
5─── The syntax diagram is continued from the previous line
───5% The syntax diagram ends here
Diagrams of syntactical units other than complete statements start with the 5───
symbol and end with the ───5 symbol.
Required items appear on the horizontal line (the main path).
55──STATEMENT──required item─────────────────────────────────────────────5%
When you can choose from two or more items, they appear vertically in a stack.
If you must choose one of the items, one item of the stack appears on the main
path.
55──STATEMENT──┬─required choice 1─┬─────────────────────────────────────5%
└─required choice 2─┘
If choosing one of the items is optional, the entire stack appears below the main
path.
55──STATEMENT──┬───────────────────┬─────────────────────────────────────5%
├─optional choice 1─┤
└─optional choice 2─┘
An arrow returning to the left above the main line indicates an item that can be
repeated.
┌──
─────────────────┐
55──STATEMENT───6─repeatable item─┴───────────────────────────────────────5%
A repeat arrow above a stack indicates that you can make more than one choice
from the stacked items, or repeat a single choice.
Keywords appear in uppercase letters (for example, PRINT). They must be spelled
exactly as shown. Variables appear in all lowercase letters (for example, item).
They represent user-supplied names or values.
If punctuation marks, parentheses, arithmetic operators, or such symbols are
shown, they must be entered as part of the syntax.
Use at least one blank or comma to separate parameters.
Where it helps to more clearly separate the examples from the explanatory text, they
are indented, presented in a different font style, or are shown in boxes.
Names of files, COBOL keywords, commands, and options appearing in text are gener-
ally shown in SMALL UPPER CASE, unless they are mixed-case, in which case they are
presented in a different font style.
Major Changes
New compiler option -host to facilitate setting of all host data compiler options
(“Options Supported by cob2” on page 136).
New compiler option ANALYZE to check the syntax of embedded SQL and CICS
statements (“ANALYZE” on page 149).
Host DBCS, removal of restriction “CHAR (EBCDIC) does not apply to DBCS
data.,” (removed from Appendix B, “System/390 Host Data Type Considerations”
on page 469 ).
Default EBCDIC code page based on run time locale, (“Locale Sensitivity” on
page 413 and “Definitions of COBOL Environment Variables” on page 129).
Enable Japanese Era and Chinese Era support in the date/time callable services.
Extension of the ACCEPT statement to cover the recommendation in the Working
Draft for Proposed Revision of ISO 1989:1985 Programming Language COBOL
(“How to Get 4-digit Year Dates” on page 444).
New intrinsic date functions.
| The millennium language extensions, enabling compiler-assisted date processing
| for dates containing 2-digit and 4-digit years (Chapter 29, “Using the Millennium
| Language Extensions” on page 446).
| New compiler option WSCLEAR to clear working storage at program initialization
| (“WSCLEAR” on page 185).
For complete details on the COBOL language, see IBM COBOL Language Reference.
Variables
In COBOL you refer to a variable by a data-name. For example, if a customer name is
a variable in your program, code:
Data Division.
.
.
ð1 Customer-Name Pic X(2ð).
ð1 Original-Customer-Name Pic X(2ð).
.
.
Procedure Division.
.
.
Move Customer-Name to Original-Customer-Name
.
.
The data used in a COBOL program can be divided into three classes: alphabetic,
alphanumeric, and numeric. For complete details on the classes and categories of data
and the PICTURE clause rules for defining data, see IBM COBOL Language Reference.
Data Structure
Related data items are often parts of a larger, hierarchical data structure. A data item
that is composed of subordinated data items is called a group item. An elementary
data item is a data item that does not have any subordinate items. A record can be
either an elementary data item or a group of data items.
Literals
When you know the value you want to use for a data item, you don't need to define or
refer to a data-name; instead use a literal representation of the data value in the Proce-
dure Division.
For example, you might want to prepare an error message for an output file:
Move “Invalid Data” To Customer-Name
Constants
COBOL does not define a construct specifically for constants, but most programmers
define a data item with an initial VALUE (as opposed to initializing a variable using the
INITIALIZE statement):
Data Division.
.
.
ð1 Report-Header pic x(5ð) value "Company Sales Report".
.
.
ð1 Interest pic 9v9999 value 1.ð265.
Figurative Constants
Certain commonly used constants and literals are provided as reserved words, called
figurative constants. Because they represent fixed values, figurative constants do not
require a data definition: ZERO, SPACE, HIGH-VALUE, LOW-VALUE, QUOTE, NULL, ALL.
The following example shows how you can reset fields in a transaction record produced
by a program to spaces and zeros. (Notice that the fields are not identical in each
record produced.)
ð1 TRANSACTION-OUT.
ð5 TRANSACTION-CODE PIC X.
ð5 PART-NUMBER PIC 9(6).
ð5 TRANSACTION-QUANTITY PIC 9(5).
ð5 PRICE-FIELDS.
1ð UNIT-PRICE PIC 9(5)V9(2).
1ð DISCOUNT PIC V9(2).
1ð SALES-PRICE PIC 9(5)V9(2).
.
.
INITIALIZE TRANSACTION-OUT
When you move a group item to another group item, be sure the subordinate data
descriptions are compatible. The compiler performs all MOVE statements regardless of
whether items fit, even if that means a destructive overlap could occur at run time. In
such cases, you'll get a warning message when you compile your program.
in the above example, where device is any valid system device (for example,
SYSIN).
-or-
Set the environment variable CONSOLE to a valid file specification using the
export command. For example:
export CONSOLE=/myfiles/myinput.rpt
Note that the environment variable must be the same as the system device used.
In the above example, the system device is Console, but the method of assigning
an environment variable to the system device name is supported for all valid
system devices. For example, if the system device is SYSIN, the environment vari-
able which must be assigned a file specification is SYSIN also).
To write data to a destination other than the system logical output unit, the UPON
clause must be used on the DISPLAY statement. For example:
Display "Hello" UPON SYSOUT
writes to the system logical output device, or to the destination specified in the
SYSOUT environment variable, if defined.
When you use the ON SIZE ERROR phrase of the COMPUTE statement, the compiler
generates code to detect a size-overflow condition. If the condition occurs, the code in
the ON SIZE ERROR phrase is performed, and the content of z remains unchanged. If
the ON SIZE ERROR phrase is not specified, the assignment is carried out with trun-
cation. There is no ON SIZE ERROR support for the MOVE statement.
For information on intrinsic functions, see the IBM COBOL Language Reference.
A function-identifier represents both the function's invocation and the data value
returned by the function. Because it actually represents a data item, a function-
identifier can be used in most places in the Procedure Division where a data item
having the attributes of the returned value can be used.
Because the value of an intrinsic function is derived automatically at the time of refer-
ence, you do not need to define functions in the Data Division. Define only the non-
literal data items that you use as arguments. Figurative constants are not allowed as
arguments.
For example, you could use SQRT to invoke an intrinsic function and/or to name a vari-
able in your program:
Working-Storage Section.
ð1 x Pic 99 value 2.
ð1 y Pic 99 value 4.
ð1 z Pic 99 value ð.
ð1 Sqrt Pic 99 value ð.
.
.
Compute Sqrt = 16 \\ .5
Compute z = x + Function Sqrt(y)
.
.
| Three functions, DATEVAL, UNDATE, and YEARWINDOW are provided with the
| millennium language extensions to assist with manipulationg and converting windowed
| date fields. For details on the millennium language extensions, see Chapter 29, “Using
| the Millennium Language Extensions” on page 446. The three functions are described
| individually in IBM COBOL Language Reference.
Numeric intrinsic functions are further classified according to the type of numbers they
return. See the IBM COBOL Language Reference for more details.
Nesting Functions
Functions can reference other functions as arguments as long as the results of the
nested functions meet the requirements for the arguments of the outer function. For
example:
Compute x = Function Max((Function Sqrt(5)) 2.5 3.5)
In this case, Function Sqrt(5) returns a numeric value. Thus, the three arguments to
the MAX function are all numeric, which are allowable argument types for this function.
Some of the examples in the next three chapters show nesting of functions.
Substrings of Function-Identifiers
You can include a substring specification (reference modifier) in your function-identifier
for alphanumeric functions.
Pointers
Pointer data items can contain virtual storage addresses. You define them explicitly
with the USAGE IS POINTER clause in the Data Division or implicitly as ADDRESS OF
special registers.
Procedure Pointers
A procedure pointer is a pointer to an entry point. Define the entry address for a proce-
dure entry point with the USAGE IS PROCEDURE-POINTER clause in the Data Divi-
sion.
To define a COBOL class or method, you need to define some divisions differently than
you would for a program. For detail on the differences, see “Writing a Class Definition”
on page 224 or “Writing a Method Definition” on page 228.
IDENTIFICATION DIVISION
Use the IDENTIFICATION DIVISION to name your program and to optionally give other
identifying information. For example:
Identification Division.
Program-ID. Helloprog.
Author. A. Programmer.
Installation. Computing Laboratories.
Date-Written. ð8/18/1997.
Date-Compiled. ð2/27/1998.
You can use the optional AUTHOR, INSTALLATION, DATE-WRITTEN, and DATE-COMPILED
paragraphs for descriptive information about your program. The data you enter on the
DATE-COMPILED paragraph is replaced with the latest compilation date.
PROGRAM-ID Paragraph
Use the PROGRAM-ID paragraph to name your program. The program name you
assign is used in these ways:
Other programs use the name to call your program.
The name appears in the header on each page, except the first page, of the
program listing generated when the program is compiled. (See “Changing Header
of Source Listing” on page 13 for details.)
RECURSIVE can be coded only on the outermost program of a compilation unit. Neither
programs containing nested subprograms nor nested subprograms can be recursive.
Definition of Initial State: Essentially, a program is in its initial state when data items
having VALUE clauses are set to the specified value, changed GO TO statements and
PERFORM statements are set to their initial states, and non-EXTERNAL files are closed.
PP 5765-548 IBM COBOL Set for AIX 1.1.ð Date ð2/27/1998 Time 15:ð5:19 Page 1
You can customize the header on succeeding pages of the listing with the compiler-
directing TITLE statement. See the IBM COBOL Language Reference for details of the
TITLE statement.
ENVIRONMENT DIVISION
In the ENVIRONMENT DIVISION you can describe those aspects of your program that are
dependent upon the characteristics of the computing environment in which you are
working.
CONFIGURATION SECTION
You can use the CONFIGURATION SECTION to describe the computer for compiling your
program (in the SOURCE-COMPUTER paragraph); describe the computer for running
your program (in the OBJECT-COMPUTER paragraph); and specify such items as the
currency sign, symbolic characters (in the SPECIAL-NAMES paragraph), and user-
defined classes (in the REPOSITORY paragraph). Figure 3 on page 15 shows a
sample of some of the entries you might include in the CONFIGURATION SECTION.
1 STANDARD-1 refers to American National Standard X3.4, Code for Information Interchange.
2 ISO 7-bit code, as defined in International 646, 7-Bit Coded Character Set for Information Processing Interchange, International
Reference.
Identification Division.
.
.
Environment Division.
Configuration Section.
Object-Computer.
Program Collating Sequence Special-Sequence.
Special-Names.
Alphabet Special-Sequence Is
"A" Also "a"
"B" Also "b"
"C" Also "c"
"D" Also "d"
"E" Also "e"
"F" Also "f"
"G" Also "g"
"H" Also "h"
"I" Also "i"
"J" Also "j"
"K" Also "k"
"L" Also "l"
"M" Also "m"
"N" Also "n"
"O" Also "o"
"P" Also "p"
"Q" Also "q"
"R" Also "r"
"S" Also "s"
"T" Also "t"
"U" Also "u"
"V" Also "v"
"W" Also "w"
"X" Also "x"
"Y" Also "y"
"Z" Also "z".
The class name can only be referenced in a class condition. (This user-defined class is
not the same concept as an object-oriented class.)
INPUT-OUTPUT SECTION:
Your IBM COBOL Set for AIX programs can process files with line sequential, sequen-
tial, indexed, or relative organization.
FILE-CONTROL Paragraph
The FILE-CONTROL paragraph associates each file in the COBOL program with a phys-
ical file known to your file system. Figure 4 shows an example of a FILE-CONTROL
paragraph for a VSAM indexed file.
.1/ The SELECT clause chooses a file in the COBOL program to be associated with
a corresponding system file.
.2/ The ASSIGN clause associates the program's name for the file with the name of
the file as known to the system. COMMUTER may be the system file name or the
name of the environment variable whose value (at run time) is used as the
system file name with optional directory and path names.
.3/ Use the ORGANIZATION clause to describe the file's organization. If omitted, the
default is ORGANIZATION IS SEQUENTIAL.
.4/ Use the ACCESS MODE clause to define the manner in which the records in the
file will be made available for processing—sequential, random, or dynamic. If
you omit this clause, ACCESS IS SEQUENTIAL is assumed.
Chapter 7, “Processing Files” on page 90 provides a general overview on files and file
processing.
You can use either an environment variable, a system file name, a literal, or a data
name in the ASSIGN clause. If you specify an environment variable, its value is evalu-
ated at run time and is used as the system file name with optional directory and path
names.
If you plan to use a file system other than the default file system, you need to select the
file system explicitly, for example, by specifying the file system identifier before the
system file name. For example, if the file MYFILE is an Encina SFS file and you use F1
as the file's name in your program, the ASSIGN clause would be
SELECT F1 ASSIGN TO VSA-MYFILE
Note that this assumes that MYFILE is a system file name and not an environment vari-
able. If MYFILE is an environment variable, then its value will be used. For example, if
it is set to MYFILE=VSAM-YOURFILE, the system file name in the ASSIGN clause becomes
YOURFILE at run time, and the file is treated as a VSAM file, overriding the file system ID
used in ASSIGN clause in the program.
export MASTERA=/accounts/savings
to do the same for the file named savings
The same program can be used to access both checking and savings files by way of
the COBOL MASTER file without source program changes or recompilation.
Environment variable values in effect at the time of the program invocation are used for
associating COBOL file names to the system file names (including any path specifica-
tions).
DATA DIVISION
Define the characteristics of your data and group your data definitions into one of the
sections in the DATA DIVISION:
Define data used in input/output operations in the FILE SECTION (discussed in
“FILE SECTION (Using Data in Input/Output Operations)”).
Define data developed for internal processing:
– To be statically allocated and exist for the life of the run-unit:
WORKING-STORAGE SECTION (discussed on page 19).
Caution: Data items defined in the FILE SECTION are not available to PROCEDURE
DIVISION statements until the file has been successfully opened.
In the record description following the FD entry describe the records and their fields
in the file. The record-name established is the object of WRITE and REWRITE state-
ments.
The application has two COBOL file names, but these COBOL files are associated with
one system file.
Most programs, however, have a combination of input and output file processing and
internal data manipulation; the data files are defined in the FILE SECTION, and the data
developed by the program is defined in the WORKING-STORAGE SECTION or
LOCAL-STORAGE section.
CBL apost,pgmn(lu)
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
\ Recursive Program - Factorials
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
Identification Division.
Program-Id. factorial recursive.
Environment Division.
Data Division.
Working-Storage Section.
ð1 numb pic 9(4) value 5.
ð1 fact pic 9(8) value ð.
Local-Storage Section.
ð1 num pic 9(4).
Procedure Division.
move numb to num.
if numb = ð
move 1 to fact
else
subtract 1 from numb
call 'factorial'
multiply num by fact
end-if.
Recursive
CALL's: Main 1 2 3 4 5
------------------------------------
L-S num 5 4 3 2 1 ð
------------------------------------
W-S numb 5 4 3 2 1 ð
fact ð ð ð ð ð ð
------------------------------------
Recursive
GOBACK's: 5 4 3 2 1 Main
------------------------------------
L-S num ð 1 2 3 4 5
------------------------------------
W-S numb ð ð ð ð ð ð
fact 1 1 2 6 24 12ð
------------------------------------
Nested Programs
An application's solution might consist of nested programs—programs that are con-
tained in other programs. Level-01 LINKAGE SECTION data items can include the
GLOBAL attribute. This allows any nested program that includes the declarations to
access these LINKAGE SECTION data items.
A nested program can also access data items in a sibling program (one at the same
nesting level in the same containing program) that is declared with the COMMON attri-
bute. For more details, see “Structure of Nested Programs” on page 324.
If you compile your program as recursive or with the THREAD option, the address to that
record is valid for the particular instance of the program invocation. The address to the
record in another execution instance of the same program must be re-established for
that execution instance. Unpredictable results will occur if reference is made to a data
item whose address has not been established.
PROCEDURE DIVISION
In the PROCEDURE DIVISION of a program you code the executable statements that
process the data you have defined in the other divisions. The PROCEDURE DIVISION
contains one or two headers and the logic of your program.
Or, you can code your division header to receive parameters with the USING phrase or
to return a value with the RETURNING Phrase.
USING Phrase
To receive an argument that was passed by reference (the default) or by content, code
the division header for a program like this:
PROCEDURE DIVISION USING dataname
Or this:
PROCEDURE DIVISION USING BY REFERENCE dataname
Take Note: dataname in these examples would need to be defined in the LINKAGE
SECTION of the program.
To receive a parameter that was passed by value, code the division header for a
program like this:
PROCEDURE DIVISION USING BY VALUE dataname
RETURNING Phrase
You can also combine USING AND RETURNING in a PROCEDURE DIVISION header:
Procedure Division USING dataname RETURNING dataname2
Take Note: dataname and dataname2 in these examples would need to be defined in
the LINKAGE SECTION.
Imperative and conditional statements can be ended implicitly or explicitly. If you end a
conditional statement explicitly, it becomes a delimited scope statement (which is an
imperative statement).
Imperative Statements
An imperative statement indicates that an unconditional action is to be taken. Exam-
ples are ADD, MOVE, INVOKE, and CLOSE. A full list of imperative statements can be
found in IBM COBOL Language Reference.
Conditional Statements
A conditional statement is either a simple conditional statement (IF, EVALUATE,
SEARCH) or a conditional statement made up of an imperative statement that includes a
conditional phrase or option.
The following are examples of conditional statements if they are coded without scope
terminators:
Data-manipulation statements with ON OVERFLOW.
CALL statements with ON OVERFLOW.
I/O statements with INVALID KEY, AT END, AT END-OF-PAGE.
RETURN with AT END.
Using the NOT Phrase: For additional program control, the NOT phrase can also be
used with conditional statements. For example, you can provide instructions to be per-
formed when a particular exception does not occur, such as NOT ON SIZE ERROR. The
NOT phrase cannot be used with the ON OVERFLOW phrase of the CALL statement, but
it can be used with the ON EXCEPTION phrase.
Compiler-Directing Statements
A compiler-directing statement is not part of the program logic. A compiler-directing
statement causes the compiler to take specific action about the program structure,
COPY processing, listing control, control flow, or CALL interface convention.
Each of the two periods in the above program fragment end the IF statements, making
the code equivalent to the following example that has explicit scope terminators:
IF CAT
DISPLAY "It is a cat."
ELSE
IF DOG
DISPLAY "It is a dog."
ELSE
DISPLAY "It is not a dog or cat."
END-IF
END-IF
If you use implicit terminators, it can be unclear where statements end. As a result,
you might end statements unintentionally, changing your program's logic. Explicit scope
terminators make a program easier to understand and prevent unintentional ending of
statements. For example, in the program fragment below, changing the location of the
first period in the first implicit scope example changes the meaning of the code:
IF ITEM = "A"
DISPLAY "VALUE OF ITEM IS " ITEM
ADD 1 TO TOTAL.
MOVE "C" TO ITEM
DISPLAY " VALUE OF ITEM IS NOW " ITEM
IF ITEM = "B"
ADD 2 TO TOTAL.
The two statements:
MOVE "C" TO ITEM
DISPLAY " VALUE OF ITEM IS NOW " ITEM
will be performed regardless of the value of ITEM, despite what the indentation indi-
cates, because the first period terminates the IF statement. For improved program
clarity and to avoid unintentional ending of statements, you should use explicit scope
terminators instead of implicit scope terminators, especially within paragraphs. Use
implicit scope terminators only at the end of a paragraph or the end of the program.
To code a conditional statement where the COBOL syntax calls for an imperative
statement.
For example, code a conditional statement as the object of an inline PERFORM:
Rules for Delimited Scope Statements: Because a period implicitly ends the scope
of all previous statements, do not use a period in a delimited scope statement.
Using Nested Delimited Scope Statements: When nested within another delimited
scope statement with the same verb, each explicit scope terminator ends the statement
begun by the most recently preceding (and as yet unpaired) occurrence of that verb.
Be careful when coding an explicit scope terminator for an imperative statement that is
nested within a conditional statement. Ensure that the scope terminator is paired with
the statement for which it was intended. In the following example, the scope terminator
will be paired with the second READ statement, though the programmer intended it to
be paired with the first.
READ FILE1
AT END
MOVE A TO B
READ FILE2
END-READ
To ensure that the explicit scope terminator is paired with the intended statement, the
preceding example can be recoded in this way:
READ FILE1
AT END
MOVE A TO B
READ FILE2
END-READ
END-READ
Declaratives
Declaratives provide one or more special-purpose sections that are executed when an
exceptional condition occurs.
Each Declarative Section starts with a USE statement that identifies the function of the
section; the series of procedures that follow specify what actions are to be taken when
the condition occurs. See the IBM COBOL Language Reference for a complete
description of declaratives and Chapter 12, “Debugging Techniques” on page 197 and
“Input/Output Error Handling Techniques” on page 118 for instances of their use.
You can code up to 18 digits in the PICTURE clause, as well as various other characters
of special significance. The "s" in the following example means that the value is
signed:
ð5 Price Pic s99v99.
The field can hold a positive or negative value. The "v" indicates the position of an
implied decimal point. Neither "s" nor "v" are counted in the size of the item, nor do
they require extra storage positions, unless the item is coded as USAGE DISPLAY with
the SIGN IS SEPARATE clause. An exception is internal floating point data (COMP-1 or
COMP-2), for which there is no PICTURE clause.
Numeric-edited items can be moved to numeric and numeric-edited items. In the fol-
lowing example, the numeric-edited item is de-edited and its numeric value is moved to
the numeric data item.
Move Edited-price to Price
Display Price
If these two statements were to immediately follow the statements shown in the pre-
vious example, then Price would be displayed as 0150099, representing the value
1,500.99.
For complete information on the data descriptions for numeric data, refer to IBM
COBOL Language Reference.
COMP and COMP-4 are synonymous with BINARY, and COMP-3 is synonymous with
PACKED-DECIMAL.
Regardless of what USAGE clause you use to control the computer's internal represen-
tation of the value, you use the same PICTURE clause conventions and decimal value in
the VALUE clause except for floating point data.
The compiler has to automatically convert displayable numbers to the internal represen-
tation of their numeric value before they can be used in arithmetic operations. There-
fore, it is often more efficient to define your data items as computational items to begin
with, rather than as DISPLAY items. For example:
ð5 Count-x Pic s9v9(5) Usage Comp Value 3.14159.
The VALUE clause is not allowed in the data description for external floating-point items.
Also, the minus signs (-) do not mean that the mantissa and exponent will always be
negative numbers, but that when displayed the sign will appear as a blank for positive
and a minus sign for negative. If a plus sign (+) were used, positive would be displayed
as a plus sign and negative as a minus sign.
Just as with external decimal numbers, external floating-point numbers have to be con-
verted (automatically by the compiler) to an internal representation of the numeric value
before they can be operated on.
Binary Items
BINARY, COMP, and COMP-4 are synonyms on all platforms. COMP-5 is a new USAGE
type based on the X/OPEN COBOL specification.
Binary format occupies 2, 4, or 8 bytes of storage and is handled for arithmetic pur-
poses as a fixed-point number with the leftmost bit being the operational sign. For
byte-reversed binary data, the sign bit is the leftmost bit of the rightmost byte.
However, you might want to use packed decimal format instead of binary because:
Binary format might not be as well suited for decimal alignment as packed decimal
format.
Binary format is not converted to and from DISPLAY format as easily as packed
decimal format.
On AIX, COMP-1 and COMP-2 data items are represented in IEEE format if the
FLOAT(NATIVE) compiler option is in effect. See “FLOAT” on page 165 for additional
information.
A PICTURE clause is not allowed in the data description of floating-point data items,
but you can provide an initial value using a floating-point literal in the VALUE clause:
ð5 Compute-result Usage Comp-1 Value ð6.23E-24.
Floating-point format is well suited for containing arithmetic operands and results and
for maintaining the highest level of accuracy in arithmetic.
For complete information on the data descriptions for numeric data, see IBM COBOL
Language Reference.
Figure 8. Internal Representation of Numeric Items—Native Data Types. This table assumes that
the CHAR(NATIVE) and FLOAT(NATIVE) compiler options are in effect.
Numeric PICTURE and USAGE and Optional
Type SIGN Clause Value Internal Representation
External PIC S9999 DISPLAY + 1234 31 32 33 34
Decimal - 1234 31 32 33 74
1234 31 32 33 34
PIC 9999 DISPLAY 1234 31 32 33 34
PIC S9999 DISPLAY + 1234 31 32 33 34
SIGN LEADING - 1234 71 32 33 34
PIC S9999 DISPLAY + 1234 2B 31 32 33 34
SIGN LEADING SEPARATE - 1234 2D 31 32 33 34
PIC S9999 DISPLAY + 1234 31 32 33 34 2B
SIGN TRAILING SEPARATE - 1234 31 32 33 34 2D
Internal PIC S9999 PACKED-DECIMAL + 1234 ð1 23 4C
Decimal COMP-3 - 1234 ð1 23 4D
PIC 9999 PACKED-DECIMAL 1234 ð1 23 4F
COMP-3
Internal COMP-1 + 1234 44 9A 4ð ðð
Floating - 1234 C4 9A 4ð ðð
Point
Internal COMP-2 + 1234 4ð 93 48 ðð ðð ðð ðð ðð
Floating - 1234 Cð 93 48 ðð ðð ðð ðð ðð
Point
External PIC +9(2).9(2)E+99 DISPLAY + 1234 2B 31 32 2E 33
Floating 34 45 2B 3ð 32
Point
- 1234 2D 31 32 2E 33
34 45 2B 3ð 32
Figure 9. Internal Representation of Numeric Items—System/390 Host Data Types. This table
assumes that the CHAR(EBCDIC) and FLOAT(HEX) compiler options are in effect.
Numeric PICTURE and USAGE and Optional
Type SIGN Clause Value Internal Representation
External PIC S9999 DISPLAY + 1234 F1 F2 F3 C4
Decimal - 1234 F1 F2 F3 D4
1234 F1 F2 F3 C4
PIC 9999 DISPLAY 1234 F1 F2 F3 F4
PIC S9999 DISPLAY + 1234 C1 F2 F3 F4
SIGN LEADING - 1234 D1 F2 F3 F4
PIC S9999 DISPLAY + 1234 4E F1 F2 F3 F4
SIGN LEADING SEPARATE - 1234 6ð F1 F2 F3 F4
PIC S9999 DISPLAY + 1234 F1 F2 F3 F4 4E
SIGN TRAILING SEPARATE - 1234 F1 F2 F3 F4 6ð
Internal PIC S9999 PACKED-DECIMAL + 1234 ð1 23 4C
Decimal COMP-3 - 1234 ð1 23 4D
PIC 9999 PACKED-DECIMAL 1234 ð1 23 4F
COMP-3
Internal COMP-1 + 1234 43 4D 2ð ðð
Floating - 1234 C3 4D 2ð ðð
Point
Internal COMP-2 + 1234 43 4D 2ð ðð ðð ðð ðð ðð
Floating - 1234 C3 4D 2ð ðð ðð ðð ðð ðð
Point
External PIC +9(2).9(2)E+99 DISPLAY + 1234 4E F1 F2 4B F3
Floating F4 C5 4E Fð F2
Point
- 1234 6ð F1 F2 4B F3
F4 C5 4E Fð F2
When possible, the compiler performs the move to preserve the numeric “value” as
opposed to a direct digit-for-digit move. (For more information on truncation and pre-
dicting the loss of significant digits, refer to Appendix C, “Intermediate Results and
Arithmetic Precision” on page 471.)
Although the compiler converts short form to long form for comparisons, zeros are used
for padding the short number.
When a USAGE COMP-1 data item is moved to a fixed-point data item with more than
6 digits, the fixed-point data item will receive only 6 significant digits, and the remaining
digits will be zero.
Conversions that Preserve Precision: If a fixed-point data item with 6 or fewer digits
is moved to a USAGE COMP-1 data item and then returned to the fixed-point data
item, the original value is recovered.
If a USAGE COMP-1 data item is moved to a fixed-point data item of 6 or more digits
and then returned to the USAGE COMP-1 data item, the original value is recovered.
If a fixed-point data item with 15 or fewer digits is moved to a USAGE COMP-2 data
item and then returned to the fixed-point data item, the original value is recovered.
If a USAGE COMP-2 data item is moved to a USAGE COMP-1 data item, rounding
occurs in the low-order position of the target data item.
If a fixed-point data item is moved to an external floating-point data item where the
PICTURE of the fixed-point data item contains more digit positions than the PICTURE
of the external floating-point data item, rounding occurs in the low-order position of the
target data item.
Given X'sd', where s is the sign representation and d represents the digit, the valid
sign representations for external decimal (USAGE DISPLAY without the SIGN IS SEP-
ARATE clause) are :
Positive: 0, 1, 2, 3, 8, 9, A, and B.
Negative: 4, 5, 6, 7, C, D, E, and F.
When the CHAR(NATIVE) compiler option is in effect, signs generated internally are 3 for
positive and unsigned, and 7 for negative.
When the CHAR(EBCDIC) compiler option is in effect, signs generated internally are C
for positive, F for unsigned, and D for negative.
Given X'ds', where d represents the digit and s is the sign representation, the valid
sign representations for internal decimal (USAGE PACKED-DECIMAL) COBOL data
are:
Positive: A, C, E, and F.
Negative: B and D.
Signs generated internally are C for positive, F for unsigned, and D for negative.
Frequently, values are passed into your program and assigned to items that have
incompatible data descriptions for those values. For example, non-numeric data might
be moved or passed into a field in your program that is defined as a numeric item. Or,
perhaps a signed number is passed into a field in your program that is defined as an
unsigned number. In either case, these fields contain invalid data. Ensure that the
contents of a data item conforms to its PICTURE and USAGE clauses before using the
data item in any further processing steps.
Performing Arithmetic
COBOL provides various language features to perform arithmetic:
ADD, SUBTRACT, MULTIPLY, DIVIDE, and COMPUTE statements (discussed in
“COMPUTE and Other Arithmetic Statements”).
Arithmetic expressions (discussed in “Arithmetic Expressions” on page 39).
Intrinsic functions (discussed in “Numeric Intrinsic Functions” on page 39).
For the complete details of syntax and usage for COBOL language constructs, refer to
IBM COBOL Language Reference.
The COMPUTE statement assigns the result of an arithmetic expression to a data item:
Compute z = a + b / c \\ d - e
or to many data items:
Compute x y z = a + b / c \\ d - e
instead of:
Compute Balance = Balance - Overdraft
Or,
Add 1 To Increment-1, Increment-2, Increment-3
instead of:
Compute Increment-1 = Increment-1 + 1
Compute Increment-2 = Increment-2 + 1
Compute Increment-3 = Increment-3 + 1
You might also prefer to use the DIVIDE statement (with its REMAINDER phrase) for
division in which you want to process a remainder. The REM intrinsic function also
provides the ability to process a remainder. For an example of the REM function, see
“Mathematics” on page 43.
Arithmetic Expressions
In the examples of COMPUTE shown above, everything to the right of the equal sign
represents an arithmetic expression. Arithmetic expressions can consist of a single
numeric literal, a single numeric data item or a single intrinsic function reference. They
can also consist of several of these items connected by arithmetic operators. These
operators are evaluated in a hierarchic order:
Operators at the same level are evaluated from left to right; however, you can use
parentheses with these operators to change the order in which they are evaluated.
Expressions in parentheses are evaluated before any of the individual operators are
evaluated. Parentheses, necessary or not, make your program easier to read.
In addition to using arithmetic expressions in COMPUTE statements, you can also use
them in other places where numeric data items are allowed. For example, you can use
arithmetic expressions as comparands in relation conditions:
If (a + b) > (c - d + 5) Then...
The numeric functions available in COBOL under these categories are described in IBM
COBOL Language Reference.
Because numeric functions and arithmetic expressions hold similar status syntactically
speaking, you can also nest an arithmetic expression as an argument to a numeric
function:
Compute x = Function Sum(a b (c / d))
In this example, there are only three function arguments: a, b and the arithmetic
expression (c / d).
General Number-Handling: Suppose you want to find the maximum value of two
prices (represented as alphanumeric items with dollar signs), put this value into a
numeric field in an output record, and determine the length of the output record. You
could use NUMVAL-C (a function that returns the numeric value of an alphanumeric
string) and the MAX function to do this:
ð1 X Pic 9(2).
ð1 Price1 Pic x(8) Value "$8ððð".
ð1 Price2 Pic x(8) Value "$2ððð.
ð1 Output-Record.
ð5 Product-Name Pic x(2ð).
ð5 Product-Number Pic 9(9).
ð5 Product-Price Pic 9(6).
.
.
.
Procedure Division.
Compute Product-Price =
Function Max (Function Numval-C(Price1) Function Numval-C(Price2))
Compute X = Function Length(Output-Record)
Additionally, to ensure that the contents in Product-Name are in uppercase letters, you
could use the following statement:
Move Function Upper-case(Product-Name) to Product-Name
Date/Time: The following example shows how to calculate a due date that is 90 days
from today. The first eight characters returned by the CURRENT-DATE function repre-
sent the date in a 4-digit year, 2-digit month, and 2-digit day format (YYYYMMDD). In
the example, this date is converted to its integer value. Then 90 is added to this value,
and the integer is converted back to the YYYYMMDD format.
The ANNUITY function can be used in business problems that require you to determine
the amount of an installment payment (annuity) necessary to repay the principal and
interest of a loan. The series of payments is characterized by an equal amount each
period, periods of equal length, and an equal interest rate each period. The following
example shows how you could calculate the monthly payment required to repay a
$15,000 loan at 12% annual interest in three years (36 monthly payments, interest per
month = .12/12):
ð1 Loan Pic 9(9)V99.
ð1 Payment Pic 9(9)V99.
ð1 Interest Pic 9(9)V99.
ð1 Number-Periods Pic 99.
..
.
Compute Loan = 15ððð
Compute Interest = .12
Compute Number-Periods = 36
Compute Payment =
Loan \ Function Annuity((Interest / 12) Number-Periods)
The following discussion explains when arithmetic and arithmetic comparisons are eval-
uated in fixed-point and floating-point. For details on the precision of arithmetic evalu-
ations, see Appendix C, “Intermediate Results and Arithmetic Precision” on page 471.
Floating-Point Evaluations
In general, if your arithmetic evaluation has either of the characteristics listed below, it
will be evaluated by the compiler in floating-point arithmetic:
An operand or result field is floating-point.
A data item is floating-point if you code it as a floating-point literal, or if you define
it as USAGE COMP-1, USAGE COMP-2, or as external floating-point (USAGE
DISPLAY with a floating-point PICTURE).
An operand that is a nested arithmetic expression or a reference to numeric
intrinsic function results in floating-point when:
– An argument in an arithmetic expression results in floating-point.
– The function is a floating-point function.
– The function is a mixed-function with one or more floating-point arguments.
An exponent contains decimal places.
This is true if you use a literal that contains decimal places, give the item a
PICTURE containing decimal places, or use an arithmetic expression or function
whose result has decimal places.
An arithmetic expression or numeric function yields a result with decimal places if
any operand or argument—excluding divisors and exponents—has decimal places.
Fixed-Point Evaluations
In general, if your arithmetic operation contains neither of the characteristics listed
above for floating-point, it will be evaluated by the compiler in fixed-point arithmetic. In
other words, your arithmetic evaluations will be handled by the compiler as fixed-point
only if all your operands are given in fixed-point, your result field is defined to be fixed-
point, and none of your exponents represent values with decimal places. Nested arith-
metic expression and function references must represent fixed-point values.
Thus, the rules outlined so far for determining whether your evaluation will be done in
fixed-point or floating-point arithmetic apply to your comparison statement as a unit.
evaluate (a + d)
when (b + e) thru c
when (f / g) thru (h \ i)
.
.
.
end-evaluate
Your comparison operation (and the evaluation of any arithmetic expressions nested in
your comparison) will be handled by the compiler as floating-point arithmetic if either of
your comparands is a floating-point value or resolves to a floating-point value.
Your comparison operation (and the evaluation of any arithmetic expressions nested in
your comparison) will be handled by the compiler as fixed-point arithmetic if both of
your comparands are fixed-point values or resolve to fixed-point values.
Use the COBOL OCCURS clause in the DATA DIVISION entry to define a table, and
you do not need separate entries for repeated data items. The OCCURS clause also
supplies the information necessary for the use of subscripts or indexes. (For more
information on the format of the OCCURS clause, refer to IBM COBOL Language Ref-
erence).
To code a table, give the table a group name and define a subordinate item (the table
element) that is to be repeated n times:
ð1 table-name.
ð5 element-name OCCURS n TIMES.
.
. (subordinate items of the table element might follow)
.
For all the tables, the table element definition (which includes the OCCURS clause) is
subordinate to the group item that contains the table; the OCCURS clause cannot
appear in a level-01 description.
To create tables of more than one dimension, use nested OCCURS clauses. Tables of
up to seven dimensions can be defined using this same method.
One Dimension
To create a one-dimensional table, use one OCCURS clause. For example:
SAMPLE-TABLE-ONE
01 SAMPLE-TABLE-ONE.
05 TABLE-COLUMN OCCURS 3 TIMES.
10 TABLE-ITEM-1 PIC X(2).
10 TABLE-ITEM-2 PIC X(1).
SAMPLE-TABLE-ONE is the group item that contains the table. TABLE-COLUMN names the
table element of a one-dimensional table that occurs three times.
Two Dimensions
To create a two-dimensional table, define a one-dimensional table in each occurrence
of another one-dimensional table. For example:
SAMPLE-TABLE-TWO
01 SAMPLE-TABLE-TWO.
05 TABLE-ROW OCCURS 2 TIMES.
10 TABLE-COLUMN OCCURS 3 TIMES.
15 TABLE-ITEM-1 PIC X(2).
15 TABLE-ITEM-2 PIC X(1).
Three Dimensions
To create a three-dimensional table, define a one-dimensional table in each occurrence
of another one-dimensional table, which is itself contained in each occurrence of
another one-dimensional table. For example:
Graphic Representation
COBOL Code
SAMPLE-TABLE-THREE
01 SAMPLE-TABLE-THREE.
05 TABLE-DEPTH OCCURS 2 TIMES.
10 TABLE-ROW OCCURS 2 TIMES.
15 TABLE-COLUMN OCCURS 3 TIMES.
20 TABLE-ITEM-1 PIC X(2).
20 TABLE-ITEM-2 PIC X(1).
The technique of supplying the occurrence number of individual table elements is called
subscripting. See page 48. A related technique, called subscripting using index-names
(indexing) is also available for table references.
An index is a symbol used to locate an item in a table. An index differs from a sub-
script in that an index is a value to be added to the address of a table to locate an item
(the displacement from the beginning of the table). See page 49.
Subscripting
The lowest possible subscript value is 1, which points to the first occurrence of the
table-element. In a one-dimensional table, the subscript corresponds to the row
number. In a two-dimensional table, the two subscripts correspond to the column and
row numbers. In a three-dimensional table, the three subscripts correspond to the
depth, column, and row numbers.
Literal Subscripts
The following are valid literal subscript references to SAMPLE-TABLE-THREE:
TABLE-COLUMN (2, 2, 1)
TABLE-COLUMN (2 2 1) (The spaces are required for subscripting.)
In the table reference TABLE-COLUMN (2, 2, 1), the first value (2) refers to the second
occurrence within TABLE-DEPTH, the second value (2) refers to the second occurrence
within TABLE-ROW, and the third value (1) refers to the first occurrence within
TABLE-COLUMN.
If a subscript is represented by a literal and the subscripted item is of fixed length, then
the compiler resolves the location of the subscripted data item within the table at
compile time.
Variable Subscripts
The following is a valid, variable subscript reference to SAMPLE-TABLE-TWO, (assuming
that SUB1 and SUB2 are data-names containing positive integer values within the range
of the table):
TABLE-COLUMN (SUB1 SUB2)
Relative Subscripts
In relative subscripting, the subscript can be incremented or decremented by a speci-
fied integer amount. Relative subscripting is valid with either literal or variable sub-
scripts. For example:
TABLE-COLUMN (SUB1 - 1, SUB2 + 3)
4. Use the index in SET, SEARCH, SEARCH ALL, PERFORM VARYING, or rela-
tional condition statements.
I = L * (S-1)
where:
To be valid during execution, an index value must correspond to a table element occur-
rence of not less than 1 nor greater than the highest permissible occurrence number.
This restriction applies to both direct and relative indexing.
Direct Indexing
In direct indexing, the index-name is in the form of a displacement. The value con-
tained in the index is then calculated as the occurrence number minus 1, multiplied by
the length of the individual table entry.
For example:
ð5 TABLE-ITEM OCCURS 1ð INDEXED BY INX-A PIC X(8).
For the fifth occurrence of TABLE-ITEM, the binary value contained in INX-A is (5 - 1) * 8
= 32.
Relative Indexing
In relative indexing, the index-name is followed by a space, followed by a + or a -,
followed by another space, followed by an unsigned numeric literal. The literal is con-
sidered to be an occurrence number, and is converted to an index value before being
added to or subtracted from the index-name.
That is,
Each occurrence of TABLE-DEPTH is 256 characters in length.
Each occurrence of TABLE-COLUMN is 64 characters in length.
Each occurrence of TABLE-ROW is 8 characters in length.
When reading data to load your table, test to make sure that the data does not exceed
the space allocated for the table. Use a named value giving the item count, rather than
using a literal. Then, if you make the table bigger, you need to change only one value,
instead of all references to a literal.
The INITIALIZE statement cannot load a variable-length table (one that was defined
using OCCURS DEPENDING ON).
For an example of this method, see "Error Flag Table” and “Error Message Table” in
Figure 15 on page 54.
This technique is practical only for small tables. To initialize larger tables, use MOVE,
PERFORM, or INITIALIZE statements, as described above.
For example:
ð1 TABLE-ONE VALUE "1234".
ð5 TABLE-TWO OCCURS 4 TIMES PIC X.
In both cases, if the ODO object has a VALUE clause, it is logically initialized after the
ODO subject has been initialized. For example:
ð1 TABLE-THREE VALUE "3ABCDE".
ð5 X PIC 9.
ð5 Y OCCURS 5 TIMES
DEPENDING ON X PIC X.
causes Y(1) to be initialized to A, Y(2) to B,... Y(5) to E, and finally the object of the
ODO (X) is initialized to 3. Any subsequent reference to TABLE-THREE (such as
DISPLAY) would refer to the first 3 elements, Y(1) through Y(3).
ð1 T2.
ð5 T-OBJ PIC 9 VALUE 3.
ð5 T OCCURS 5 TIMES DEPENDING ON T-OBJ.
1ð X PIC XX VALUE "AA".
1ð Y PIC 99 VALUE 19.
1ð Z PIC XX VALUE "BB".
causes all the X elements (1 through 5) to be initialized to AA, all the Y elements (1
through 5) to be initialized to 19, and all the Z elements (1 through 5) to be initialized to
BB. T-OBJ is then set to 3.
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
\\\ E R R O R F L A G T A B L E \\\
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
ð1 Error-Flag-Table Value Spaces.
88 No-Errors Value Spaces.
ð5 Type-Error Pic X.
ð5 Shift-Error Pic X.
ð5 Home-Code-Error Pic X.
ð5 Work-Code-Error Pic X.
ð5 Name-Error Pic X.
ð5 Initials-Error Pic X.
ð5 Duplicate-Error Pic X.
ð5 Not-Found-Error Pic X.
ð5 Address-Error Pic X.
ð5 City-Error Pic X.
ð5 State-Error Pic X.
ð5 Zipcode-Error Pic X.
ð5 Home-Phone-Error Pic X.
ð5 Work-Phone-Error Pic X.
ð5 Home-Junction-Error Pic X.
ð5 Work-Junction-Error Pic X.
ð5 Driving-Status-Error Pic X.
ð1 Filler Redefines Error-Flag-Table.
ð5 Error-Flag Occurs 17 Times
Indexed By Flag-Index Pic X.
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
\\\ E R R O R M E S S A G E T A B L E \\\
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
ð1 Error-Message-Table.
ð5 Filler Pic X(25) Value
"Transaction Type Invalid".
ð5 Filler Pic X(25) Value
"Shift Code Invalid".
ð5 Filler Pic X(25) Value
"Home Location Code Inval.".
Figure 15 (Part 1 of 2). Table with Static Values Defined for Every Table Element
Figure 15 (Part 2 of 2). Table with Static Values Defined for Every Table Element
Perform
Varying Sub From 1 By 1
Until No-Errors
If Error-Flag (Sub) = Error-On
Move Space To Error-Flag (Sub)
Move Error-Message (Sub) To Print-Message
Perform 26ð-Print-Report
End-If
End-Perform
Set Flag-Index To 1
Perform Until No-Errors
Search Error-Flag
When Error-Flag (Flag-Index) = Error-On
Move Space To Error-Flag (Flag-Index)
Set Message-Index To Flag-Index
Move Error-Message (Message-Index) To
Print-Message
Perform 26ð-Print-Report
End-Search
End-Perform
If the receiving item is followed by a data-item which is in the same record but is not
subordinate to the receiver (is complex ODO), then the actual length is used and a
compiler message is issued to inform you that the actual length, not the maximum, will
be used. In this situation it is necessary to set the value of the ODO object before any
reference to the item.
The following example contrasts how the length is determined for a group item whose
subordinate items contain an OCCURS clause with the DEPENDING ON option and
ð1 REC-2.
ð5 REC-2-DATA PIC X(5ð).
As you can see, you must be sure that you have the correct value placed in the ODO
object before the MOVE is initiated.
In this case, the ODO object (FIELD-1) need not be set before referencing REC-1 as a
receiving item. However, the sending field's ODO object needs to be set to a valid
numeric value between 1 and 5 for the ODO object of the receiving field to be validly
set by the move.
If you do a MOVE to REC-1 in this case, the actual length of REC-1 is calculated imme-
diately prior to the move using the current value of the ODO object (FIELD-1), and a
compiler message is issued letting you know that the actual length, instead of the
maximum length, was used. This case requires that you set the value of the ODO
object (FIELD-1) prior to using the item as a receiving field.
DATA DIVISION.
FILE SECTION.
FD LOCATION-FILE.
ð1 LOCATION-RECORD.
ð5 LOC-CODE PIC XX.
ð5 LOC-DESCRIPTION PIC X(2ð).
ð5 FILLER PIC X(58).
WORKING-STORAGE SECTION.
ð1 FLAGS.
ð5 LOCATION-EOF-FLAG PIC X(5) VALUE SPACE.
88 LOCATION-EOF VALUE "FALSE".
ð1 MISC-VALUES.
ð5 LOCATION-TABLE-LENGTH PIC 9(3) VALUE ZERO.
ð5 LOCATION-TABLE-MAX PIC 9(3) VALUE 1ðð.
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
\\\ L O C A T I O N T A B L E \\\
\\\ FILE CONTAINS LOCATION CODES. \\\
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
ð1 LOCATION-TABLE.
ð5 LOCATION-CODE OCCURS 1 TO 1ðð TIMES
DEPENDING ON LOCATION-TABLE-LENGTH PIC X(8ð).
Two factors that affect the successful manipulation of variable-length records are the
correct calculation of records lengths and the conformance of the data in the
OCCURS...DEPENDING ON object to its picture. If you are using variable-length group
items in either a READ...INTO or WRITE...FROM statement, in conjunction with an
OCCURS...DEPENDING ON statement, make sure that the receiver or intermediate
field length is correct. The length of the variable portions of a group item is the product
of the object of the DEPENDING ON option and the length of the subject of the
OCCURS clause.
If the content of the ODO object does not match its PICTURE clause, the program may
abnormally terminate. See Chapter 3, “Numbers and Arithmetic” on page 29 for more
information on data and sign representation.
Complex ODO is tricky to use and can make maintaining your code more difficult. If
you choose to use it in order to save disk space, follow the guidelines in Appendix D,
“Complex OCCURS DEPENDING ON” on page 479.
To perform binary searches, use indexing and the SEARCH ALL statement.
The following discussion assumes you are familiar with the format of the SEARCH and
SEARCH ALL statements. If you are not, see IBM COBOL Language Reference.
Serial Search
Use the SEARCH statement to perform a serial search beginning at the current index
setting. To modify the index setting, use the SET statement.
The conditions in the WHEN option are evaluated in the order in which they are written.
If none of the conditions is satisfied, the index is increased to correspond to the
next table element, and the WHEN conditions are evaluated again.
If one of the WHEN conditions is satisfied, the search ends; the index remains
pointing to the table element that satisfied the condition.
If the entire table has been searched and no conditions were met, the AT END
imperative statement is executed, if there is one. If you do not use the AT END
option, control passes to the next statement in your program.
Arranging the table so that the data used most often is at the beginning also enables
more efficient serial searching. If the table is large and is pre-sorted, a binary search is
more efficient. See “Binary Search (SEARCH ALL Statement)” on page 61 more infor-
mation on binary searches.
To use the SEARCH ALL statement, your table must be ordered on the key or keys
coded in the OCCURS clause. You can use any key in the WHEN condition, but all
preceding data-names in the KEY option must also be tested. The test must be an
equal-to condition, and the KEY data-name must be either the subject of the condition
or the name of a conditional variable with which the tested condition-name is associ-
ated. The WHEN condition can also be a compound condition, formed from one of the
simple conditions listed above, with AND as the only logical connective. The KEY and
its object of comparison must be compatible, as stated in the relation test rules.
These instructions will execute a search on the given table that contains 90 elements of
40 bytes and 3 keys. The primary and secondary keys (KEY-1 and KEY-2) are in
ascending order, but the least significant key (KEY-3) is in descending order. If an entry
is found in which three keys are equal to the given values (VALUE-1, VALUE-2, and
VALUE-3), PART-1 of that entry will be moved to OUTPUT-AREA. If the matching keys are
not found in any of the entries in TABLEA, the NOENTRY routine is performed.
Example 1
This example sums a cross section of Table-Two:
Compute Table-Sum = FUNCTION SUM (Table-Two(ALL, 3, ALL)))
Assuming that Table2 is a 2x3x2 array, the above statement would cause these ele-
ments to be summed:
Table-Two(1,3,1)
Table-Two(1,3,2)
Table-Two(2,3,1)
Table-Two(2,3,2)
Example 2
This example computes values for all employees.
ð1 Employee-Table.
ð5 Emp-Count Pic s9(4) usage binary.
ð5 Emp-Record occurs 1 to 5ðð times
depending on Emp-Count.
1ð Emp-Name Pic x(2ð).
1ð Emp-Idme Pic 9(9).
1ð Emp-Salary Pic 9(7)v99.
.
.
Procedure Division.
Compute Max-Salary = Function Max(Emp-Salary(ALL))
Compute I = Function Ord-Max(Emp-Salary(ALL))
Compute Avg-Salary = Function Mean(Emp-Salary(ALL))
Compute Salary-Range = Function Range(Emp-Salary(ALL))
Compute Total-Payroll = Function Sum(Emp-Salary(ALL))
Example 3
Scalars and array arguments can be mixed for functions that accept multiple
arguments:
Compute Table-Median = Function Median(Arg1 Table-One(ALL))
Selection is providing for different program actions depending on the tested value of
some data item or data items.
The IF and EVALUATE statements are COBOL selection constructs. The testing of a
data item or data items is done in both of these statements by means of a conditional
expression.
IF Statement
Use IF . . . ELSE to code a choice between two processing actions. (The word THEN is
optional in a COBOL program.) For example:
IF condition-p
statement-1
ELSE
statement-2
END-IF
Nested IF Statements
When an IF statement has another IF statement as one of its possible processing
branches, these IF statements are said to be nested IFs. Theoretically, there is no limi-
tation on the depth of nested IF statements. However, when the program has to test a
variable for more than two values, EVALUATE is the better choice. (For more informa-
tion, see “EVALUATE statement” on page 66).
Use nested IF statements sparingly; the logic can be difficult to follow, although proper
indentation helps.
Here an IF is nested, along with a sequential structure, in one branch of another IF.
The structure for this logic is shown in Figure 20 on page 65.
When you code a structure like the one in Figure 20, the END-IF closing the inner
nested IF becomes very important. Use END-IF instead of a period, because a period
would end the outer IF structure as well.
Statement 1 Statement 3
True
condition-q
True
False Statement 4
Good Coding Practice for Nested IFs: When you nest IF statements, readability and
debugging will be easier if each IF statement has its own END-IF scope-terminator and if
you use proper indentation. For example:
IF A = 1
IF B = 2
PERFORM C
ELSE PERFORM D.
The ELSE PERFORM D phrase is interpreted as the ELSE phrase of the last previous IF
which is, IF B = 2. If this is the intent, you can make the logic clearer with the fol-
lowing coding:
IF A = 1
IF B = 2
PERFORM C
ELSE
PERFORM D
END-IF
END-IF
If the intent is to have ELSE PERFORM D depend on IF A = 1, the code would look like
this:
IF A = 1
IF B = 2
PERFORM C
END-IF
ELSE
PERFORM D
END-IF
EVALUATE statement
The EVALUATE statement is an expanded form of the IF statement. An IF statement
allows your program to act on one of two conditions: true or false. If you had three or
more possible conditions instead of just two, and you were limited to using IF state-
ments, you would need to nest or cascade the IF statements. Such nested IF state-
ments are a common source of logic errors and debugging problems.
With the EVALUATE statement, you can test any number of conditions in a single state-
ment and have separate actions for each. In structured programming terms, this is a
case structure. It can also be thought of as a form of decision table.
Conditional Expressions
The IF and EVALUATE statements let you code different program actions that will be
performed depending on the true or false value of a condition expression. COBOL lets
you specify any of these simple conditions:
You can create combined conditions by using logical connectives (AND, OR, or NOT),
and you can combine conditions. Rules for using conditions are given in IBM COBOL
Language Reference.
Some program decisions are based not on an on or off condition of a data item, but
instead, depend on the particular value (or range of values) of a data item. When
condition-names are used to give more than just on or off values to a field, the field is
generally referred to as a flag, not a switch. For details on flags, see the section
“Flags” on page 68, below.
Flags and Switches Make Changing Code Easier: Flags and switches make your
code easier to change. If you need to change the values for a condition, you have to
change only the level-88 condition-name value.
For example, a program that uses a condition-name to test a field for a given numeric
range—a salary range—need not be changed. If the program must be changed to
check for a different salary range, you would need to change only the condition-name
value in the DATA DIVISION. You do not need to make changes in the PROCEDURE
DIVISION.
Switches: For example, to test for an end-of-file condition for an input file named
Transaction-File, you could use the following data definitions:
Working-Storage Section.
ð1 Switches.
ð5 Transaction-EOF-Switch Pic X value space.
88 Transaction-EOF value "y".
The level-88 description says a condition named Transaction-EOF is turned on when
Transaction-EOF-Switch has a value of "y". Referencing Transaction-EOF in your
PROCEDURE DIVISION expresses the same condition as testing for
Transaction-EOF-Switch = "y". For example, the statement:
If Transaction-EOF Then Perform Print-Report-Summary-Lines
causes the report to be printed only if your program has read through to the end of the
Transaction-File and if the Transaction-EOF-Switch has been set to "y".
Flags: To test for more than two values, assign more than one condition-name to a
field by using multiple level-88 items.
Consider a program that updates a master file. The updates are read from a trans-
action file. The transaction file's records contain a field for the function to be per-
formed: add, change, or delete. In the input file's record description, code a field for the
function code using level-88 items:
ð1 Transaction-Input Record
ð5 Transaction-Type Pic X.
88 Add-Transaction Value "A".
88 Change-Transaction Value "C".
88 Delete-Transaction Value "D".
The code in the PROCEDURE DIVISION for testing these condition-names might look like
this:
Evaluate True
When Add-Transaction
Perform Add-Master-Record-Paragraph
When Change-Transaction
Perform Update-Exisitng-Record-Paragraph
When Delete-Transaction
Perform Delete-Master-Record-Paragraph
End-Evaluate
SET condition-name TO TRUE: When you use the SET condition-name TO TRUE
statement, the switch or flag is set back to the original value it was assigned in its data
description.
This method makes it easy for the reader to follow your code if you choose meaningful
condition-names and if the value assigned has some association with a logical value of
True.
The SET statement in the following example does the same thing as Move "y" to
Transaction-EOF-Flag:
ð1 Switches
ð5 Transaction-EOF-Switch Pic X Value space.
88 Transaction-EOF Value "y".
.
.
.
Procedure Division.
ððð-Do-Main-Logic.
Perform 1ðð-Initialize-Paragraph
Read Update-Transaction-File
At End Set Transaction-EOF to True
End-Read
The following example shows how you can assign a value for a field in an output record
based on the transaction code of an input record.
ð1 Input-Record.
ð5 Transaction-Type Pic X(9).
.
.
.
ð1 Data-Record-Out.
ð5 Data-Record-Type Pic X.
88 Record-Is-Active Value "A".
88 Record-Is-Suspended Value "S".
88 Record-Is-Deleted Value "D".
ð5 Key-Field Pic X(5).
.
.
.
Procedure Division.
.
.
.
Evaluate Transaction-Type of Input-Record
When "ACTIVE"
Set Record-Is-Active to TRUE
When "SUSPENDED"
Set Record-Is-Suspended to TRUE
When "DELETED"
Set Record-Is-Deleted to TRUE
End-Evaluate
Level-88 Note: For a level-88 item with multiple values (such as 88
Record-is-Active Value "A" "O" "S"), SET condition-name TO TRUE assigns the first
value (here, A).
Then use SWITCH-OFF throughout your program to set on/off switches to off. With this
method, whoever reads your code can easily see what you are doing to a switch. From
this code:
ð1 Switches
ð5 Transaction-EOF-Switch Pic X Value space.
88 Transaction-EOF Value "y".
ð1 SWITCH-OFF Pic X Value "n".
.
.
.
Procedure Division.
.
.
.
Move SWITCH-OFF to Transaction-EOF-Switch
it is easy to see that you are setting the end-of-file switch to off. In other words, you
have reset the switch to indicate that the end of the file has not been reached.
Use the PERFORM statement to run a paragraph and then implicitly return control to the
next executable statement. In effect, the PERFORM statement is a way of coding a
closed subroutine that you can enter from many different parts of the program.
When control reaches the PERFORM statement, the code for the paragraph
ð1ð-PROCESS-ONE-MONTH is executed 12 times before control is transferred to the
INSPECT statement.
Conditional Looping
Use the PERFORM . . . UNTIL statement to execute a paragraph until a condition you
choose is satisfied. You can use either of the following forms:
PERFORM . . . WITH TEST AFTER . . . UNTIL . . .
PERFORM . . . [WITH TEST BEFORE] . . . UNTIL . . .
In the following example, the implicit WITH TEST BEFORE phrase provides a do-while
structure:
PERFORM ð1ð-PROCESS-ONE-MONTH
UNTIL MONTH EQUAL DECEMBER
INSPECT . . .
When control reaches the PERFORM statement, the condition (MONTH EQUAL DECEMBER)
is tested. If the condition is satisfied, control is transferred to the INSPECT statement. If
the condition is not satisfied, ð1ð-PROCESS-ONE-MONTH is executed, and the condition is
tested again. This cycle continues until the condition tests as true. (To make your
program easier to read, you might want to code the WITH TEST BEFORE clause.)
Use the PERFORM . . . WITH TEST AFTER . . . UNTIL if you want to execute the para-
graph at least once and then test before any subsequent execution. This is equivalent
to the do-until structure.
\\\ BLANK FIELDS ARE NOT ALLOWED IN THE INPUT DATA \\\
INSPECT . . .
In the code above, when control reaches the PERFORM statement, WS-DATA-IX is set
equal to 1 and the PERFORM statement is executed. Then the condition (WS-DATA-IX =
12) is tested. If the condition is true, control drops through to the INSPECT statement.
If it is false, WS-DATA-IX is increased by 1, the PERFORM statement is executed, and the
condition is tested again. This cycle of execution and testing continues until WS-DATA-IX
is equal to 12.
In terms of the application, this loop controls input-checking for the 12 fields of item
WS-DATA. Empty fields are not allowed, and this section of code loops through and
issues error messages, as appropriate.
WHEN YOU USE PERFORM . . . THRU use a paragraph-EXIT statement to clearly indicate
the end point for the series of paragraphs.
Intrinsic functions can make the task of the iterative processing of tables simpler and
easier for you to code. For information on using the ALL subscript with intrinsic func-
tions to reference all the items in a table, see “Processing Table Items (Intrinsic
Functions)” on page 62.
The STRING statement transfers data into the receiving item in the order you indicate.
In the STRING statement you can also specify:
Delimiters that cause a sending field to be ended and another to be started
Special actions to be taken when an ON OVERFLOW condition occurs (when the
single receiving field is filled before all of the sending characters have been proc-
essed).
ð1 RCD-ð1.
ð5 CUST-INFO.
1ð CUST-NAME PIC X(15).
1ð CUST-ADDR PIC X(35).
ð5 BILL-INFO.
1ð INV-NO PIC X(6).
1ð INV-AMT PIC $$,$$$.99.
1ð AMT-PAID PIC $$,$$$.99.
1ð DATE-PAID PIC X(8).
1ð BAL-DUE PIC $$,$$$.99.
1ð DATE-DUE PIC X(8).
In the PROCEDURE DIVISION, the programmer initializes RPT-LINE to SPACES and sets
LINE-POS, the data item to be used as the POINTER field, to 4. (By coding the POINTER
phrase of the STRING statement, you can use the explicit pointer field to control place-
ment of data in the receiving field.) Then, the programmer issues this STRING
statement:
STRING
LINE-NO SPACE CUST-INFO INV-NO SPACE DATE-DUE SPACE
DELIMITED BY SIZE
BAL-DUE
DELIMITED BY DEC-POINT
INTO RPT-LINE
WITH POINTER LINE-POS.
After the STRING statement is performed, RPT-LINE appears as shown in the following:
Column
4 1ð 6ð 67 76
│ │ │ │ │
│ │ │ │ │
6 6 6 6 6
ðððð1 J.B. SMITH 444 SPRING ST., CHICAGO, ILL A14275 1ð/22/76 $2,336
You can indicate delimiters that, when encountered in the sending field, cause the
current receiving field to be switched to the next one indicated. You might have the
number of characters placed in each receiving field returned to you, and keep a count
of the total number of characters transferred. You might also specify special actions for
the program to take if all the receiving fields are filled before the end of the sending
item is reached.
\
\ UNSTRING receiving field for further processing:
ð1 WORK-REC.
ð5 M-UNITS PIC 9(6).
ð5 FIELD-A PIC 9(6).
ð5 WK-PRICE REDEFINES FIELD-A PIC 9999V99.
ð5 INV-CLASS PIC X(3).
\
\ UNSTRING statement control fields
77 DBY-1 PIC X.
77 CTR-1 PIC S9(3).
77 CTR-2 PIC S9(3).
77 CTR-3 PIC S9(3).
77 CTR-4 PIC S9(3).
77 DLTR-1 PIC X.
77 DLTR-2 PIC X.
77 CHAR-CT PIC S9(3).
77 FLDS-FILLED PIC S9(3).
Before issuing the UNSTRING statement, the programmer places the value 3 in CHAR-CT
(the POINTER field) to avoid working with the two control characters in INV-RCD. A
period (.) is placed in DBY-1 for use as a delimiter, and the value 0 (zero) is placed in
FLDS-FILLED (the TALLYING field). The data is then read into INV-RCD, as shown in the
following:
Column
1 1ð 2ð 3ð 4ð 5ð 6ð
│ │ │ │ │ │ │
│ │ │ │ │ │ │
│ │ │ │ │ │ │
6 6 6 6 6 6 6
ZYFOUR─PENNY─NAILS 7ð789ð/BBA 47512ð ðð122 ððð379.5ð
8. Because all receiving fields have been acted on and 2 characters of data in
INV-RCD have not been examined, the ON OVERFLOW exit is taken, and execution
of the UNSTRING statement is completed.
SPACE Note: In steps 4, 5, and 6, the delimiter is a SPACE, but because no field has
been defined as a receiving area for delimiters, the SPACE is bypassed.
Using a SEARCH statement to locate trailing null or space characters (Define the
string being examined as a table of single characters.)
Checking each character in a field in a loop (PERFORM) looking at each character
of the field (Each character in the field can be examined using a reference modifier
such as source-field (I:1).)
The following example shows how to use a reference modifier to reference a substring
of a data item:
Move Customer-Record(1:2ð) to Orig-Customer-Name
As this shows, in parentheses immediately following the data item you code the ordinal
position (from the left) of the character you want the substring to start with and the
length of the desired substring, separated by a colon.
The length is optional. If you omit the length, the substring created will automatically
extend to the end of the item. Omitting the length, when possible, is recommended as
a simpler, less error-prone coding technique.
Both numbers in the reference modifier must be at least 1, and their sum should not
exceed the total length of the data item.
The following options detect out-of-range reference modifiers and flag violations with a
run-time message:
SSRANGE compiler option, discussed on page 178.
CHECK run-time option, discussed on page “CHECK” on page 193.
For additional information on reference modification, see IBM COBOL Language Refer-
ence.
Without reference notification you would have to define data items for both formats, the
one from the system and the one you want, and write code to convert from one format
to the other.
With reference modification, you do not need to provide names for the subfields that
describe the TIME elements. The only data definition needed is:
ð1 REFMOD-TIME-ITEM PIC X(8).
The code to retrieve and expand the time value would appear as follows:
Suppose that a field contains some characters, right-justified, and you want to move the
characters to another field, but justified to the left instead of the right. Using reference
modification and an INSPECT statement, you could do that.
The program would count the number of leading spaces and, using arithmetic
expressions in a reference modification expression, move the right-justified characters
into another field, left-justified:
MOVE SPACES TO LEFTY
MOVE ZERO TO I
| INSPECT RIGHTY
TALLYING I FOR LEADING SPACE.
IF I IS LESS THAN LENGTH OF RIGHTY THEN
MOVE RIGHTY ( I + 1 : LENGTH OF RIGHTY - I ) TO LEFTY
END-IF
The MOVE statement transfers characters from RIGHTY, beginning at the position com-
puted in I + 1, for a length that is computed in LENGTH OF RIGHTY - I, into the field
LEFTY.
For example:
ð5 WS-name Pic x(2ð).
ð5 Left-posn Pic 99.
ð5 I Pic 99.
.
.
Move Customer-Record(Function Min(Left-posn I):Function Length(WS-name)) to WS-name
For a list that shows which numeric functions return integer and non-integer results, see
IBM COBOL Language Reference.
Example 1:
77 COUNTR PIC 9 VALUE ZERO.
ð1 DATA-2 PIC X(11).
.
.
INSPECT DATA-2
TALLYING COUNTR FOR LEADING "ð"
REPLACING FIRST "A" BY "2" AFTER INITIAL "C"
Example 2:
77 COUNTR PIC 9 VALUE ZERO.
ð1 DATA-3 PIC X(8).
.
.
INSPECT DATA-3
REPLACING CHARACTERS BY ZEROS BEFORE INITIAL QUOTE
Example 3:
The following example shows the use of INSPECT CONVERTING with AFTER and
BEFORE phrases. The table shows examples of the contents of DATA-4 before and after
the conversion statement is performed.
ð1 DATA-4 PIC X(11).
.
.
INSPECT DATA-4
CONVERTING
"abcdefghijklmnopqrstuvwxyz" TO
"ABCDEFGHIJKLMNOPQRSTUVWXYZ"
AFTER INITIAL "/"
BEFORE INITIAL"?"
Besides using intrinsic functions to convert characters, you can also use the INSPECT
statement. See the examples under “Tallying and Replacing Data Items (INSPECT
Statement)” on page 82.
The difference between NUMVAL and NUMVAL-C is that NUMVAL-C is used when the
argument includes a currency symbol and/or comma, as shown in the example. You
can also place an algebraic sign in front or in the rear, and it will be processed. The
arguments must not exceed 18 digits (not including the editing symbols). For exact
syntax rules, see IBM COBOL Language Reference.
Numeric Result: Both NUMVAL and NUMVAL-C return long (double-precision) floating-
point values. A reference to either of these functions, therefore, represents a reference
to a numeric data item. For more information on characteristics of numeric data, see
Chapter 3, “Numbers and Arithmetic” on page 29.
On the other hand, if you know what position in the collating sequence you want but
don't know what character it corresponds to, then reference the CHAR function using
the integer ordinal position as the argument, and CHAR will return the desired character:
INITIALIZE Customer-Name REPLACING ALPHABETIC BY Function Char(65)
Finding the Largest or Smallest Data Item (MAX, MIN, ORD-MAX, ORD-MIN)
If you have two or more alphanumeric data items and want to know which data item
contains the largest value (evaluated according to the collating sequence), use the MAX
or ORD-MAX function, supplying the data items in question as arguments. If you want to
know which item contains the smallest value, you would use the MIN or ORD-MIN func-
tion.
If the ORD-MAX function were used in the example above, you would receive a syntax
error message at compile time, because you would be attempting to reference a
numeric function in an invalid place (see IBM COBOL Language Reference). The fol-
lowing is a valid example of the ORD-MAX function:
Compute x = Function Ord-max(Arg1 Arg2 Arg3)
This would assign the integer 3 to x, if the same arguments were used as in the pre-
vious example. If ORD-MIN were used instead, the integer 2 would be returned.
The above examples would probably be more realistic if Arg1, Arg2 and Arg3 were
instead successive elements of an array (table). For information on using table ele-
ments as function arguments, see the section on “Processing Table Items (Intrinsic
Functions)” on page 62 in Chapter 4, “Handling Tables.”
In the following example, the amount of data moved to R3 and the results of the
COMPUTE statement depend on the values and sizes of R1 and R2:
ð1 R1 Pic x(1ð) value "e".
ð1 R2 Pic x(ð5) value "f".
ð1 R3 Pic x(2ð) value spaces.
ð1 L Pic 99.
.
.
Move Function Max(R1 R2) to R3
Compute L = Function Length(Function Max(R1 R2))
Here, R2 is evaluated to be larger than R1. Therefore, assuming that the symbol ␣
represents a blank space, the string “f␣␣␣␣” would be moved to R3 (the unfilled char-
acter positions in R3 are padded with spaces), and L evaluates to the value 5. If R1
were the value “g” then R1 would be larger than R2, and the string “g␣␣␣␣␣␣␣␣␣” would
be moved to R3 (the unfilled character positions in R3 would be padded with spaces);
the value 10 would be assigned to L.
You might be dealing with variable-length output from alphanumeric functions. Plan
your program code accordingly. For example, you might need to think about using
variable-length record files when it is possible that the records you will be writing might
be of different lengths:
File Section.
FD Output-File.
ð1 Customer-Record Pic X(8ð).
Working-Storage Section.
ð1 R1 Pic x(5ð).
ð1 R2 Pic x(7ð).
.
.
Write Customer-Record from Function Max(R1 R2)
Whereas the LENGTH function can only be used where arithmetic expressions are
allowed, the LENGTH OF special register can be used in a greater variety of contexts.
For example, the LENGTH OF special register can be used as an argument to an
intrinsic function that allows integer arguments. (An intrinsic function cannot be used as
an operand to the LENGTH OF special register.) The LENGTH OF special register can
also be used as a parameter in a CALL statement.
This chapter provides a brief introduction on file organization and access modes,
describes the coding your COBOL programs need to identify and process files, and
explains how files must be defined and identified to the operating system before your
program can process them.
Record-oriented files that are organized as sequential, relative, indexed, or line sequen-
tial (byte stream) files are accessed through a file system. An application can use file-
system functions to create and manipulate the records in any of these types of files.
Two ways you can select a file system are by setting the assignment-name environ-
ment variable or by using the FILESYS run-time option. See “Accessing Files” on
page 96 for futher details. All the file systems allow you to use COBOL statements to
read or write COBOL files.
If you have more complex requirements which are not covered in this book, or are
going to be a frequent user of file systems, you should review publications for the
SMARTdata Utilities for AIX, which are provided as part of the on-line documentation.
Figure 24 summarizes file organization, access modes, and record lengths for COBOL
files.
File Organization
You can organize your files as sequential, line sequential, indexed, or relative.
After you have placed a record into the file, you cannot shorten, lengthen, or delete it.
However, you can update (REWRITE) a record if the length does not change. New
records are added at the end of the file.
Line sequential files that are created with WRITE statements with the ADVANCING
phrase can be directed to a printer (as well as a disk).
An indexed file can also use alternate indexes—record keys that let you access the file
using a different logical arrangement of the records. For example, you could access
the file through employee department rather than through employee number.
The record transmission (access) modes allowed for indexed files are sequential,
random, or dynamic. When indexed files are read or written sequentially, the sequence
is that of the key values. For a description of random and dynamic record trans-
mission, see “File Access Modes” on page 93.
The record transmission modes allowed for relative files are sequential, random, or
dynamic. When relative files are read or written sequentially, the sequence is that of
the relative record number. For a description of random and dynamic record trans-
mission, see “File Access Modes” on page 93.
You can access records in indexed and relative files in three ways: sequentially, ran-
domly, or dynamically.
Sequential Access
Code ACCESS IS SEQUENTIAL in the FILE-CONTROL entry.
For indexed files, records are accessed in the order of the key field selected (either
primary or alternate).
For relative files, records are accessed in the order of the relative record numbers.
Random Access
Code ACCESS IS RANDOM in the FILE-CONTROL entry.
For indexed files, records are accessed according to the value you place in a key field.
For relative files, records are accessed according to the value you place in the relative
key.
Dynamic Access
Code ACCESS IS DYNAMIC in the FILE-CONTROL entry.
For example, suppose you had an indexed file of employee records, and the employ-
ee's hourly wage formed the record key. Also, suppose your program was interested in
those employees earning between $7.00 and $9.00 per hour and those earning $15.00
per hour and above. To do this, retrieve the first record randomly (with a random-
retrieval READ) based on the key of 0700. Next, begin reading sequentially (using
READ NEXT) until the salary field exceeds 0900. You would then switch back to a
random read, this time based on a key of 1500. After this random read, switch back to
reading sequentially until you reach the end of the file.
IDENTIFICATION DIVISION.
.
.
ENVIRONMENT DIVISION.
INPUT-OUTPUT SECTION.
FILE-CONTROL.
SELECT filename ASSIGN TO assignment-name .1/ .2/
ORGANIZATION IS org ACCESS MODE IS access .3/ .4/
FILE STATUS IS file-status .5/
.
.
DATA DIVISION.
FILE SECTION.
FD filename
ð1 recordname .6/
nn . . . fieldlength & type .7/ .8/
nn . . . fieldlength & type
.
.
WORKING-STORAGE SECTION
ð1 file-status PICTURE 99.
.
.
PROCEDURE DIVISION.
.
.
OPEN iomode filename .9/
.
.
READ filename
.
.
WRITE recordname
.
.
CLOSE filename
.
.
STOP RUN.
.1/ filename
Any valid COBOL name. You must use the same filename on the SELECT and the
FD statements, and on the OPEN, READ, START, DELETE, and CLOSE statements.
This name is not necessarily the actual name of the file as known to the system.
Each file requires its own SELECT, FD, and input/output statements. For WRITE
and REWRITE, you specify a record defined for the file.
.2/ assignment-name
You can specify ASSIGN TO assignment-name to specify the target file-system ID
and the file of the name as known to the system directly, or you can set a value
indirectly by using an environment variable.
If you want to have the system file name identified at OPEN time, you can specify
ASSIGN USING data-name. The value of data-name at the time of the execution of
the OPEN statement for the file is used and has the system file identification
optionally preceded by the file-system type identification.
The following example illustrates how inventory-file is dynamically (by way of a
MOVE statement) associated with a file /user/inventory/parts.
SELECT inventory-file ASSIGN USING a-file...
..
.
FILE SECTION.
FD inventory-file ...
..
.
MOVE "/user/inventory/parts" TO a-file
OPEN INPUT inventory-file
The following example illustrates how inventory-file is dynamically (by way of a
MOVE statement) associated with the index file parts and the alternate index files
altpart1 and altpart2, associated with the fully-qualified DCE Cell-Relative name
(/.:/Encina/sfs in this example) for the Encina server.
SELECT inventory-file ASSIGN USING a-file...
ORGANIZATION IS INDEXED
ACCESS MODE IS DYNAMIC
RECORD KEY IS FILESYSFILE-KEY
ALTERNATE RECORD KEY IS ALTKEY1
ALTERNATE RECORD KEY IS ALTKEY2
..
.
FILE SECTION.
FD inventory-file ...
..
.
WORKING-STORAGE SECTION.
ð1 a-file PIC X(8ð) VALUE ' '.
..
.
MOVE "/.:/Encina/sfs/parts(/.:/Encina/sfs/parts;altpart1,/.:/
Encina/sfs/parts;altpart2)" TO a-file
OPEN INPUT inventory-file
For more information, see IBM COBOL Language Reference.
.3/ org
Indicates the organization: LINE SEQUENTIAL, SEQUENTIAL, INDEXED, or RELATIVE.
If this clause is omitted, the default is ORGANIZATION SEQUENTIAL.
.4/ access
Indicates the access mode, SEQUENTIAL, RANDOM, or DYNAMIC. If this clause is
omitted, the default is ACCESS SEQUENTIAL.
.5/ file-status
The 2-character COBOL FILE STATUS key.
.6/ recordname
The name of the record used in the WRITE and REWRITE statements. You can
specify more than one record for a file.
.7/ fieldlength
The logical length of the field.
.8/ type
Must match the file's record format. If you break the record description entry
beyond the level-01 description, each element should map accurately against the
record's fields.
.9/ iomode
Specifies the open mode. For example, if you are only reading from a file, code
INPUT. If you are only writing to it, code OUTPUT or EXTEND. If you are doing
both, code I-O.
Line Sequential: I-O is not a valid parameter of OPEN for line sequential files.
Accessing Files
Your programs are able to access STL, VSAM, and Encina SFS files.
Use assignment-name to specify both the file you want to access and the file system to
be used. For a detailed description of assignment-name, see the IBM COBOL Lan-
guage Reference.
The general syntax involved in making an assignment to a file stored in an alternate file
system is:
SELECT file ASSIGN TO FileSystemID-Filename
FileSystemID
Identifies the file system as one of the following:
If the file-system specification is not provided, then the run-time option FILESYS is
used to select the file system. If a file system is not specified using FILESYS, the
default is VSAM.
Filename
| The file you want to access. Alternatively, you can specify an environment variable
| to allow you to specify the file name at run time. For details, see “Run-Time Envi-
| ronment Variables” on page 130, and the IBM COBOL Language Reference.
Given that you have defined the environment variable MYFILE , (for example,
export MYFILE=STL-MYFILE), the following assignment would be valid:
SELECT file1 ASSIGN TO MYFILE
In the following example, the SELECT clause is used to associate a file on OS/390 with
a file in your workstation program:
SELECT myfile ASSIGN TO TARGETFILE
You can associate myfile to an OS/390 file called MVSMAST by setting the TARGETFILE
environment variable:
set TARGETFILE=/user/MVSMAST
where the directory USER is set to point to the specific OS/390 node and MVSMAST is
the data set name on the OS/390 system.
Figure 28 shows the possible combinations of input/output statements for line sequen-
tial files. The 'X' indicates that the statement can be used with the open mode given
at the top of the column.
Figure 29 shows the possible combinations with indexed and relative files. The 'X'
indicates that the statement can be used with the open mode given at the top of the
column.
Figure 29 (Page 1 of 2). Valid COBOL Statements with Indexed Files and Relative Files
COBOL OPEN OPEN OPEN OPEN
Access Mode Statement INPUT OUTPUT I-O EXTEND
Sequential OPEN X X X X
WRITE X X
START X X
READ X X
REWRITE X
DELETE X
CLOSE X X X X
Random OPEN X X X
WRITE X X
START
READ X X
REWRITE X
DELETE X
CLOSE X X X
Figure 29 (Page 2 of 2). Valid COBOL Statements with Indexed Files and Relative Files
COBOL OPEN OPEN OPEN OPEN
Access Mode Statement INPUT OUTPUT I-O EXTEND
Dynamic OPEN X X X
WRITE X X
START X X
READ X X
REWRITE X
DELETE X
CLOSE X X X
The file position indicator is not used or affected by the output statements WRITE,
REWRITE, or DELETE. The file position indicator has no meaning for random proc-
essing.
Opening a File
Before your program can use any WRITE, START, READ, REWRITE, or DELETE state-
ments to process records in a file, it must first open the file with an OPEN statement.
The OPEN processing is affected by whether or not the file exists, and whether or not
the OPTIONAL attribute is specified on the file definition.
For example, an OPEN EXTEND of a file that is neither optional nor available results in
file status 35, and the OPEN statement fails. If the file is OPTIONAL, the OPEN EXTEND
will create the file and return file status 05.
Figure 30 shows the COBOL statements used when creating or extending a new or
existing file.
Line Sequential: OPEN I-O is not valid for line sequential files.
If you open a sequential, line sequential, or relative file as EXTEND, the added records
are placed after the last existing records in the file.
If you open an indexed file as EXTEND, each record you add must have a record key
higher than the highest record in the file.
Records in sequential and line sequential files can be retrieved only in the sequence in
which they were written.
Sequentially
According to the ascending order of the key you are using, the RECORD KEY or the
ALTERNATE RECORD KEY, beginning at the current position of the file position indi-
cator for indexed files, or according to ascending relative record locations for rela-
tive files.
Randomly
In any order, depending on how you set the RECORD KEY or ALTERNATE RECORD
KEY or the RELATIVE KEY before your READ request.
Dynamically
Mixed sequential and random.
With dynamic access, you can switch between reading a specific record directly and
reading records sequentially, by using READ NEXT and READ PREVIOUS for sequential
retrieval, and READ for random retrieval (by key).
When you want to read sequentially, beginning at a specific record, use START before
the READ NEXT or the READ PREVIOUS statements to set the file position indicator to
point to a particular record (see “File Position Indicator” on page 100). When you code
START followed by READ NEXT, the next record is read and the file position indicator is
reset to the next record. When you code START followed by READ PREVIOUS, the
previous record is read and the file position indicator is reset to the previous record.
The file position indicator can be moved randomly by using START, but all reading is
done sequentially from that point.
You can continue to read records sequentially, or you can use the START statement to
move the file position indicator. For example:
START file-name KEY IS EQUAL TO ALTERNATE-RECORD-KEY
When a direct READ is performed for an indexed file, based on an alternate index for
which duplicates exist, only the first record in the file (base cluster) with that alternate
key value is retrieved. You need a series of READ NEXT statements to retrieve each of
the data set records with the same alternate key. A FILE STATUS value of '02' is
returned if there are more records with the same alternate key value to be read; a value
of '00' is returned when the last record with that key value has been read.
Figure 31 shows the statements that you can use in the PROCEDURE DIVISION for
sequential, line sequential, indexed, and relative files.
For indexed files, new records must be written in ascending key sequence. If the file is
opened EXTEND, the record keys of the records to be added must be higher than the
highest primary record key on the file when the file was opened.
For relative files, the records must be in sequence. If you include a RELATIVE KEY
data-item in the SELECT clause, the relative record number of the record to be written is
placed in that data item.
When ACCESS IS SEQUENTIAL, the record to be deleted must first be read by the
COBOL program. The DELETE then removes the record that was just read. If the
DELETE is not preceded by a successful READ, the deletion is not done and the status
key value is set to 92.
When ACCESS IS RANDOM or ACCESS IS DYNAMIC, the record to be deleted need not
be read by the COBOL program. To delete a record, the key of the record to be
deleted is moved to the RECORD KEY data item and the DELETE is issued. Check the
file status key after each DELETE statement.
COBOL has special language features that assist in sort and merge operations. For
information on the COBOL sort and merge language, see IBM COBOL Language Ref-
erence.
Figure 33 on page 107 is an example of the ENVIRONMENT DIVISION and DATA DIVI-
SION entries needed to describe sort files and an input file.
ID Division.
Program-ID. SmplSort.
Environment Division.
Input-Output Section.
File-Control.
\
\ Assign Name For A Sort File Is
\ Treated As Documentation.
\
Select Sort-Work-1 Assign To SortFile.
Select Sort-Work-2 Assign To SortFile.
Select Input-File Assign To InFile.
Data Division.
File Section.
SD Sort-Work-1
Record Contains 1ðð Characters.
ð1 Sort-Work-1-Area.
ð5 Sort-Key-1 Pic X(1ð).
ð5 Sort-Key-2 Pic X(1ð).
ð5 Filler Pic X(8ð).
SD Sort-Work-2
Record Contains 3ð Characters.
ð1 Sort-Work-2-Area.
ð5 Sort-Key Pic X(5).
ð5 Filler Pic X(25).
FD Input-File
ð1 Input-Record Pic X(1ðð).
.
.
.
Working-Storage Section.
ð1 EOS-Sw Pic X.
ð1 Filler.
ð5 Table-Entry Occurs 1ðð Times
Indexed By X1 Pic X(3ð).
.
.
.
Figure 33. ENVIRONMENT DIVISION and DATA DIVISION Entries for a Sort Program
– To request that output procedures be performed on the sort records after they
are sorted, use SORT . . . OUTPUT PROCEDURE.
See “Coding the Output Procedure” on page 110 for more information on
output procedures.
Sort data items (including tables) in Working-Storage.
Read records directly into a new file without any preliminary processing (SORT . . .
USING).
Transfer sorted records from the sort program directly to another file without any
further processing (SORT . . . GIVING).
The sort operation then arranges the entire set of records in the sequence specified by
the key(s).
After the sort, sorted records can be made available one at a time through a RETURN
statement to an output procedure. If you want to put the sorted records in files without
changing or processing these records, the SORT statement GIVING option names the
output files and writes the sorted records to the output files.
In the example below, SORT-GRID-LOCATION and SORT-SHIFT are defined in the DATA
DIVISION before they are used in the SORT statement.
The example also shows the use of an input and an output procedure. Use an input
procedure if you want to process the records before you sort them, and use an output
procedure if you want to further process the records after you sort them.
DATA DIVISION.
.
.
.
SD SORT-FILE
RECORD CONTAINS 115 CHARACTERS
DATA RECORD SORT-RECORD.
ð1 SORT-RECORD.
ð5 SORT-KEY.
1ð SORT-SHIFT PIC X(1).
1ð SORT-GRID-LOCATION PIC X(2).
1ð SORT-REPORT PIC X(3).
ð5 SORT-EXT-RECORD.
1ð SORT-EXT-EMPLOYEE-NUM PIC X(6).
1ð SORT-EXT-NAME PIC X(3ð).
1ð FILLER PIC X(73).
PROCEDURE DIVISION.
.
.
.
SORT SORT-FILE
ON ASCENDING KEY SORT-GRID-LOCATION SORT-SHIFT
INPUT PROCEDURE 6ðð-SORT3-INPUT
OUTPUT PROCEDURE 7ðð-SORT3-OUTPUT.
.
.
.
For DBCS keys, the collating sequence is that specified by the locale setting in effect at
execution time.
6ðð-SORT3-INPUT-PROC SECTION.
PERFORM WITH TEST AFTER
VARYING X1 FROM 1 BY 1 UNTIL X1 = 1ðð
RELEASE SORT-WORK-2-AREA FROM TABLE-ENTRY (X1)
END-PERFORM.
Each output procedure must be contained in either a section or a paragraph and must
include:
At least one RETURN or RETURN INTO statement.
The RETURN statement makes each sorted record available to your output proce-
dure (the RETURN statement for a sort file is similar to a READ statement for an
input file).
You can use the AT END and END-RETURN phrases with the RETURN statement.
The imperative statements on the AT END phrase will be performed after all the
records have been returned from the sort file. The END-RETURN explicit scope ter-
minator serves to delimit the scope of the RETURN statement.
If you use the RETURN INTO statement, instead of RETURN, your records will be
returned to Working-Storage or to an output area.
Any statements necessary to process the records that are made available, one at a
time, by the RETURN statement.
You can use ALTER, GO TO, and PERFORM statements in the input/output proce-
dure to refer to procedure-names outside the input/output procedure. However,
you must return to the input/output procedure after a GO TO or PERFORM state-
ment.
The remainder of the PROCEDURE DIVISION must not contain any transfers of
control to points inside the input/output procedure (with the exception of the return
of control from a Declarative Section).
In a SORT or MERGE input or output procedure, calling a program is permitted, but
the called program cannot issue a SORT or MERGE statement and the called
program must return to the caller.
The MERGE statement combines the files you name into one sequenced file. The files
to be merged must be already be in the same sorted sequence.
The merge operation compares keys in the records of the input files, and passes the
sequenced records one-by-one to the RETURN statement of an output procedure or to
the file named in the GIVING phrase.
The return code or completion code is stored in a SORT-RETURN special register. The
contents of SORT-RETURN change after each SORT or MERGE statement is performed.
You should test for successful completion after each SORT or MERGE statement:
SORT SORT-WORK-2
ON ASCENDING KEY SORT-KEY
INPUT PROCEDURE IS 6ðð-SORT3-INPUT-PROC
OUTPUT PROCEDURE IS 7ðð-SORT3-OUTPUT-PROC.
IF SORT-RETURN NOT=ð
DISPLAY "SORT ENDED ABNORMALLY. SORT-RETURN = "
SORT-RETURN.
.
.
.
6ðð-SORT3-INPUT-PROC SECTION.
.
.
.
7ðð-SORT3-OUTPUT-PROC SECTION.
.
.
.
Control then returns to the statement following the SORT or MERGE statement.
If you do not reference SORT-RETURN anywhere in your program, COBOL will test the
return code. If the code is 16, COBOL issues a run-time diagnostic message and ter-
minates the run unit (or the thread, in a multithread environment). If you test
SORT-RETURN for one or more (but not necessarily all) SORT or MERGE statements,
COBOL will not check the return code.
sort control statements. See SMARTsort for OS/2 and AIX for information about the
SMARTsort options file.
The file system is safe for use with threads; it is your responsibility to ensure that mul-
tiple threads do not access COBOL buffers at the same time. Multiple threads can
perform operations on the same STL file, but you must use a pthread_cond_wait or its
equivalent to force all but one of them to wait for the file access to complete on the
active thread.
With the STL file system you can easily read and write files to be shared with PL/I
programs.
After an input/output operation, data-name-1 will contain a status code which is inde-
pendent of the file system used. If you specify data-name-2, it will contain a status
code that is file-system specific. In the case of the STL file system, data-name-2 will
contain one of the STL file system return codes shown in Figure 35.
See IBM COBOL Language Reference for additional information on the FILE STATUS
clause.
The action taken by your error-handling code can vary from trying to handle the situ-
ation and continue, to issuing a message, to halting the running of the program. In any
event, coding a warning message is a good idea.
You might be able to create your own error-detection routines for data-entry errors or
for errors as your installation defines them.
COBOL contains special elements to help you anticipate and correct error conditions.
These fall into the following main areas:
“STRING and UNSTRING Operations.”
“Arithmetic Operations” on page 117.
“Input/Output Error Handling Techniques” on page 118.
“CALL Statements” on page 126.
Figure 36. Data Values before and after the Statement is Performed
Data Value Value
Item PICTURE Before After
Item-1 X(5) AAAAA AAAAA
Item-2 X(5) EEEAA EEEAA
Item-3 X(2) EA EA
Item-4 X(8) ␣␣␣␣␣␣␣␣ ␣␣␣␣␣␣␣␣
String-ptr 9(2) ð ð
Note: The symbol ␣ represents a blank space.
Because String-ptr has a value of zero that falls short of the receiving field, an over-
flow condition occurs and the STRING operation is not completed (a String-ptr greater
than nine would cause the same result). If ON OVERFLOW had not been specified, you
would not be notified that the contents of Item-4 remain unchanged.
Arithmetic Operations
When your program performs arithmetic operations, the results might be larger than the
fixed-point field that is to hold them, or you might have tried a division by 0. In either
case, the ON SIZE ERROR clause after the ADD, SUBTRACT, MULTIPLY, DIVIDE, or
COMPUTE statement can handle the situation.
For ON SIZE ERROR to work correctly for fixed-point overflow and decimal overflow, you
must specify the TRAP(ON) run-time option.
If you code the ON SIZE ERROR clause, the imperative statement of your clause will be
performed and your result field will not be changed in the following five cases:
Fixed-point overflow.
Division by 0.
Zero raised to the zero power.
Zero raised to a negative number.
A negative number raised to a fractional power.
DIVIDE-TOTAL-COST.
DIVIDE TOTAL-COST BY NUMBER-PURCHASED
GIVING ANSWER
ON SIZE ERROR
DISPLAY "ERROR IN DIVIDE-TOTAL-COST PARAGRAPH"
DISPLAY "SPENT " TOTAL-COST, " FOR " NUMBER-PURCHASED
PERFORM FINISH
END-DIVIDE
.
.
.
FINISH.
STOP RUN.
In this example, if division by 0 occurs, the program will write out a message identifying
the trouble and halt program execution.
When an input/output statement operation fails, COBOL will not perform corrective
action for you. You choose whether your program will continue running after a less-
than-severe input/output error occurs.
COBOL offers five techniques for intercepting and handling certain input/output errors.
End-of-file phrase (AT END)
EXCEPTION/ERROR declarative
FILE STATUS key
File System Return Code
INVALID KEY phrase
The most important thing to remember about input/output errors is that you choose
whether your program will continue running after a less-than-severe input/output error
occurs. COBOL does not perform corrective action. If you choose to have your
program continue (by incorporating error-handling code into your design), you must also
code the appropriate error-recovery procedure; for example, a procedure to check the
file status key value.
Figure 37 on page 119 shows the flow of logic after a file system input/output error
occurs:
Terminate
Severe yes Issue error
COBOL
error message
Program
?
no
Set Status
Key (if
present)
Evaluate All
End-of-File error type Others
E3
Invalid
Key
Return to
COBOL Program
at the end of
the I/O statement
For example, suppose you are processing a file containing transactions in order to
update a master file:
PERFORM UNTIL TRANSACTION-EOF = "TRUE"
READ UPDATE-TRANSACTION-FILE INTO WS-TRANSACTION-RECORD
AT END
DISPLAY "END OF TRANSACTION UPDATE FILE REACHED"
MOVE "TRUE" TO TRANSACTION-EOF
END READ
.
.
END-PERFORM
Sometimes, however, the condition will reflect an error. You code the AT END phrase of
the READ statement to handle either case, according to your program design.
If you code an AT END phrase, on end-of-file the phrase is performed. If you do not
code an AT END phrase, the associated ERROR declarative is performed.
Any NOT AT END phrase you code is performed only if the READ statement completes
successfully. If the READ operation fails because of any condition other than end-of-file,
neither the AT END nor the NOT AT END phrase is performed. Instead, control passes
to the end of the READ statement after performing any associated declarative proce-
dure.
If you have coded neither an AT END phrase nor an EXCEPTION declarative procedure,
but have coded a status key clause for the file, control passes to the next sequential
instruction after the input/output statement that detected the end-of-file (where presum-
ably you have some coding to take appropriate action).
EXCEPTION/ERROR Declarative
You can code one or more ERROR declarative procedures in your COBOL program that
will be given control if an input/output error occurs. You can have:
A single, common procedure for the entire program.
Group procedures for each file open mode (whether INPUT, OUTPUT, I-O, or
EXTEND).
Place each such procedure in the declaratives section of your PROCEDURE DIVISION.
(For the syntax detail, see IBM COBOL Language Reference.
In your procedure, you can choose to try corrective action, retry the operation, continue,
or end execution. You can use the ERROR declaratives procedure in combination with
the file status key if you want a further analysis of the error.
If you continue processing a blocked file, you might lose the remaining records in a
block after the record that caused the error.
Write an ERROR declarative procedure if you want the system to return control to your
program after an error occurs. If you do not write an ERROR declarative procedure,
your job could be canceled or abnormally terminated after an error occurs.
data-name-1
Specifies the 2-character COBOL FILE STATUS key that should be defined in the
WORKING-STORAGE SECTION.
Restriction: The data-name in the FILE STATUS clause cannot be variably located.
(For more information on variably located data items, see Appendix D, “Complex
OCCURS DEPENDING ON” on page 479.)
Your program can check the COBOL FILE STATUS key to discover whether an error has
been made and, if so, what general type of error it is. For example, if a FILE STATUS
clause is coded like this:
FILE STATUS IS FS-CODE
FS-CODE is used by COBOL to hold status information like this:
FS─CODE
┌──────────┬──────────┐
│ 2 │ 1 │
└──────────┴──────────┘
& &
│ └────────── Sequence error
│
└────────── Invalid key
This is especially important since it allows you to determine the cause of a file
input/output exception which might have occurred as a result of, for example, an
application logic error or a disk error.
Check the FILE STATUS key after every input/output request.
After an input or output statement is performed, check the contents of the status
key; if it contains a value other than 0, your program can issue an error message,
or can act based on the value of the code placed in the status key.
You do not have to reset the status key code, because it is set following each
input/output attempt.
For VSAM, STL, and Encina SFS files, in addition to the file status key, you can
code a second identifier in the FILE STATUS clause to get more detailed information
on file system input/output requests. For further details, see “File System Return
Code” on page 123.
You can use the status key alone, or in conjunction with the INVALID KEY option, or
to supplement the EXCEPTION/ERROR declarative. Using the status key in this way
gives you precise information about the results of each input/output operation.
IDENTIFICATION DIVISION.
PROGRAM-ID. SIMCHK.
ENVIRONMENT DIVISION.
INPUT-OUTPUT SECTION.
FILE-CONTROL.
SELECT MASTERFILE ASSIGN TO AS-MASTERA
FILE STATUS IS MASTER-CHECK-KEY
.
.
DATA DIVISION.
.
.
WORKING-STORAGE SECTION.
ð1 MASTER-CHECK-KEY PIC X(2).
.
.
PROCEDURE DIVISION.
.
.
OPEN INPUT MASTERFILE
IF MASTER-CHECK-KEY NOT = "ðð"
DISPLAY "Non-zero file status returned from OPEN " MASTER-CHECK-KEY
.
.
data-name-1
Specifies the 2-character COBOL FILE STATUS key.
data-name-2
Specifies a data item that contains the file system return code when the COBOL
FILE STATUS key is not 0. data-name-2 is at least 6 bytes long.
See the IBM COBOL Language Reference for the rules for coding data-name-2.
For information about possible return codes from the STL file system, see “File Status
and the STL File System” on page 113.
For information on interpreting the codes for other file systems, refer to the relevant file
system documentation listed in “Bibliography” on page 562.
IDENTIFICATION DIVISION.
PROGRAM-ID. EXAMPLE.
ENVIRONMENT DIVISION.
INPUT-OUTPUT SECTION.
FILE-CONTROL.
SELECT FILESYSFILE ASSIGN TO FILESYSFILE
ORGANIZATION IS INDEXED
ACCESS DYNAMIC
RECORD KEY IS FILESYSFILE-KEY
FILE STATUS IS FS-CODE, FILESYS-CODE.
DATA DIVISION.
FILE SECTION.
FD FILESYSFILE
RECORD 3ð.
ð1 FILESYSFILE-REC.
1ð FILESYSFILE-KEY PIC X(6).
1ð FILLER PIC X(24).
WORKING-STORAGE SECTION.
ð1 RETURN-STATUS.
ð5 FS-CODE PIC XX.
ð5 FILESYS-CODE PIC X(6).
PROCEDURE DIVISION.
OPEN INPUT FILESYSFILE.
DISPLAY "OPEN INPUT FILESYSFILE FS-CODE: " FS-CODE.
Figure 39 (Part 1 of 2). Getting File System Code Information on Input/Output Requests
IF FS-CODE = "ðð"
PERFORM READ-NEXT UNTIL FS-CODE NOT = "ðð"
END-IF.
CLOSE FILESYSFILE.
STOP RUN.
READ-NEXT.
READ FILESYSFILE NEXT.
DISPLAY "READ NEXT FILESYSFILE FS-CODE: " FS-CODE.
IF FS-CODE NOT = "ðð"
PERFORM FILESYS-CODE-DISPLAY
END-IF.
DISPLAY FILESYSFILE-REC.
FILESYS-CODE-DISPLAY.
DISPLAY "FILESYS-CODE ==>", FILESYS-CODE.
Figure 39 (Part 2 of 2). Getting File System Code Information on Input/Output Requests
INVALID KEY phrases operate for only limited types of errors, whereas the ERROR
declarative encompasses all forms.
INVALID KEY phrases are coded directly onto the input/output verb, whereas ERROR
declaratives are coded separately.
INVALID KEY phrases are specific for one single input/output operation, whereas
ERROR declaratives are more general.
If you code INVALID KEY in a statement that causes an INVALID KEY condition, control is
transferred to the INVALID KEY imperative statement. Here, any ERROR declaratives
you have coded are not performed.
For example, assume you have a file containing master customer records and need to
update some of these records with information in a transaction update file. You will
read each transaction record, find the corresponding record in the master file, and
make the necessary updates. The records in both files each contain a field for a cus-
tomer number, and each record in the master file has a unique customer number.
The FILE-CONTROL entry for the master file of customer records includes statements
defining indexed organization, random access, MASTER-CUSTOMER-NUMBER as the prime
record key, and CUSTOMER-FILE-STATUS as the file status key. The following example
shows how you can use FILE STATUS with the INVALID KEY to more specifically deter-
mine the cause of an I/O statement failure.
.
. (read the update transaction record)
.
MOVE "TRUE" TO TRANSACTION-MATCH
MOVE UPDATE-CUSTOMER-NUMBER TO MASTER-CUSTOMER-NUMBER
READ MASTER-CUSTOMER-FILE INTO WS-CUSTOMER-RECORD
INVALID KEY
DISPLAY "MASTER CUSTOMER RECORD NOT FOUND"
DISPLAY "FILE STATUS CODE IS: " CUSTOMER-FILE-STATUS
MOVE "FALSE" TO TRANSACTION-MATCH
END-READ
CALL Statements
When dynamically calling a separately compiled program, the program that you call
might be unavailable to the system. For example, the system could run out of storage
or it could be unable to locate the load module. If you do not have an ON EXCEPTION
or ON OVERFLOW clause on the CALL statement, your application might abend.
Use the ON EXCEPTION clause to perform a series of statements and to perform your
own error handling. For example:
MOVE "REPORTA" TO REPORT-PROG
CALL REPORT-PROG
ON EXCEPTION
DISPLAY "Program REPORTA not available, using REPORTB.'
MOVE "REPORTB" TO REPORT-PROG
CALL REPORT-PROG
END-CALL
END-CALL
If program REPORTA is unavailable, control will continue with the ON EXCEPTION clause.
ON EXCEPTION Limitation: The ON EXCEPTION clause applies only to the availability
of the called program. If an error occurs while the called program is running, the ON
EXCEPTION clause will not be performed.
To specify environment variables, use the export command. There are two ways to set
environment variables:
Temporarily, by defining the environment variable using the export command from
an AIX command prompt
Persistently, by defining the environment variable using the export command in
the .profile file in your home directory
To compile and run a simple COBOL program, the only environment variables that
need to be set are NLSPATH and LANG. These are usually set at installation.
3 All examples in this chapter assume that you are running the AIX implementation of the Korn shell. If you are running the Bourne
shell, you should separate the definition of your environment variables and the export of those variables into two steps rather than
combine them in a single shell command. The C shell uses setenv().
DB2DBDFT
Is one way of specifying the database for compiling your programs with
embedded SQL statements. See “Compiling with the DB2 Co-Processor” on
page 354 for more information on connecting to the target database.
FileSystemID
Identifies the file system as one of the following:
Note: Specify the VSAM file system when you want to access SFS
files.
If the file system specification is not provided, the run-time option
FILESYS is used to select the file system. If FILESYS is not set, the
default is VSAM.
Filename
The file you want to access.
Alternatively, you can specify an environment variable (for details, see the
IBM COBOL Language Reference).
Defaults: None. You must set all assignment-names. If you make an assign-
ment to a user-defined word that was not set as an environment variable, the
assignment is made to a file with the literal name of the user-defined word
(OUTPUTFILE in our earlier example). If the assignment is valid, this file is written
to the current directory.
COBMSGS
Specifies the name of a file to which run-time error messages will be written. To
capture run-time error messages into a file, use the export command to set
COBMSGS to a file name. If your program has a run-time error that terminates
the application, the file that COBMSGS is set to will contain the error message
indicating the reason for termination.
Defaults: None. If COBMSGS is not set, error messages are written to the ter-
minal.
COBPATH
Specifies directory path(s) to be used by the COBOL run time to locate dynam-
ically called programs. This variable must be set to run programs that require
dynamic loading. For example:
export COBPATH=/pgmpath/pgmdll
Defaults: None. You must define COBPATH if you have dynamically called pro-
grams.
COBRTOPT
Specifies the COBOL run-time options. The run-time options are separated by a
comma or a colon. Use parentheses or equal signs (=) as the delimiters for sub-
options. Options are not case sensitive.
For example:
export COBRTOPT="check(ON),UPSI(ðððððððð)"
is the equivalent of:
export COBRTOPT="CHECK=on,UPSI=ðððððððð"
Defaults: Individual run-time option defaults apply (see Chapter 11, “Run-Time
Options” on page 193).
EBCDIC_CODEPAGE
Specifies an EBCDIC code set applicable to the EBCDIC data being processed
by programs compiled with the CHAR(EBCDIC) or CHAR(S390) compiler option.
To set the EBCDIC code set, issue the command:
export EBCDIC_CODEPAGE=codepage
where codepage is the name of the code set to be used.
If EBCDIC_CODEPAGE is not set, it will default to the EBCDIC code page of the
current locale. If multiple code pages are available for the current locale the
CHAR(EBCDIC) compiler option must be set, “CHAR” on page 151 discusses this
option.
Refer to “Locales and Code Sets Supported on AIX” on page 408 for the sup-
ported code set translations.
LANG
Specifies the national language locale name in effect for message catalogs and
help files. LANG must always be set and is given an initial value during installa-
tion. The run-time library uses LANG to access the message catalog. For
example, the following command sets the language locale name to U.S. English:
export LANG=en_US
If LANG is not set correctly, run-time messages appear in an abbreviated form.
Therefore, if your messages appear incorrect, consult your installation documen-
tation to ensure that LANG is correctly defined.
Defaults: Set at installation of the operating system.
LC_COLLATE
Determines the locale to be used to define the behaviour of ranges, equivalence
classes, and multicharacter collating elements.
Defaults: The locale specified by the LANG environment variable is used.
LC_MESSAGES
Determines the locale which defines the language in which messages are written.
Defaults: The locale specified by the LANG environment variable is used.
LC_TIME
Determines the locale for date and time formatting information.
Defaults: The locale specified by the LANG environment variable is used.
LIBPATH
Specifies the full path name for the COBOL run-time library.
Defaults: Set at installation.
LOCPATH
Specifies the search path where the locale information database exists. It is a
colon-separated list of directory names. It is used at the time of setting up the
locale for a process.
NLSPATH
Specifies the full path name of message catalogs and help files. NLSPATH must
always be set and is given an initial value during installation. The run-time library
uses NLSPATH to access the message catalog.
You can set NLSPATH with the following commands:
DIR=xxxx
NLSPATH=$DIR/%L/%N:$NLSPATH
export NLSPATH
Where xxxx denotes the directory where COBOL was installed. The directory
xxxx must contain a directory xxxx/en_US (in the case of an U.S. English-
language setup) that contains the COBOL message catalog.
When you set NLSPATH, be sure to add to the NLSPATH, not replace it. Other
programs might use this environment variable.
If NLSPATH is not set correctly, run-time messages appear in an abbreviated
form. Therefore, if your messages appear incorrect, consult your installation doc-
umentation to ensure that NLSPATH is correctly defined.
Defaults: At COBOL Set for AIX installation, NLSPATH is set to
usr/lib/nls/msg/%L/%N:/usr/lib/nls/msg/prime/%N. COBOL Set for AIX instal-
lation puts the messages in usr/lib/nls/msg/xx, where xx is any language that
COBOL Set for AIX supports. The default is en_US.
SYSIN, SYSIPT, SYSOUT, SYSLIST, SYSLST, CONSOLE, SYSPUNCH, SYSPCH
These COBOL environment names are used as the environment variable names
corresponding to the mnemonic names used on ACCEPT and DISPLAY state-
ments. For example, the following command defines CONSOLE:
export CONSOLE=/users/mypath/myfile
CONSOLE could then be used in conjunction with the following COBOL source
code:
SPECIAL-NAMES.
CONSOLE IS terminal
...
DISPLAY 'Hello World' UPON terminal
Defaults: SYSIN and SYSIPT are directed to the logical input device (keyboard).
SYSOUT, SYSLIST, SYSLST, and CONSOLE are directed to the system logical
output device (screen). SYSPUNCH and SYSPCH are not assigned a value by
default and are not valid unless you explicitly define them.
TEMP
Specifies the location of temporary work files (if needed) for SORT and MERGE
functions. For example:
export TEMP=/tmp
Defaults: Vary. Set by the sort utility installation program.
TZ
This variable is used to describe the time zone information to be used by the
locale and has the following format:
export TZ=SSS[+|-]nDDD[,sm,sw,sd,st,em,ew,ed,et,shift]
The values for the TZ variable are defined below.
For example:
export TZ=CST6CDT
sets the standard time zone to CST, the daylight saving time to CDT, and sets a
difference of 6 hours between CST and UTC. It does not set any values for the
start and end of daylight saving time.
Other possible values are PST8PDT for Pacific United States and MST7MDT for
Mountain United States.
When TZ is not present, the default is EST5EDT, the default locale value. When
only the standard time zone is specified, the default value of n (difference in
hours from GMT) is 0 instead of 5.
If you give values for any of sm, sw, sd, st, em, ew, ed, et, or shift, you must give
values for all of them. If any of these values is not valid, the entire statement is
considered not valid, and the time zone information is not changed.
If you compile with the THREAD option, use cob2_r rather than cob2. If you use the
SFS file system, use cob2_r4 rather than cob2. All the rules for cob2 apply equally to
cob2_r and cob2_r4.
55──cob2──┬─────────┬──filenames──────────────────────────────────────5%
└─options─┘
Is equivalent to:
cob2 filea.cbl -g -qflag(w) fileb.cbl -qlib
Usage Notes
1. Any options specified apply to all files on the command line.
2. Only files with the .cbl extension are passed to the compiler—cob2 passes all
other files to the linker. The linker accepts .o files, but does not accept .c files. If
you want to link C and COBOL files, first produce .o files using xlc -c.
3. The default location for compiler input and output is the current directory.
4. The linker causes execution to begin at the first main program. For example:
4 For information on ld, the AIX linker command, see the AIX Commands Reference.
See also Chapter 23, “Building Shared Libraries” on page 386 for descriptions of Static
Linking and Shared Libraries, and how to create shared object code libraries.
| -cmain Make a C or PL/I object file containing a main routine5 the main entry
| point in the executable file.
| Warning: If a C or PL/I object file containing a main routine is linked
| with one or more COBOL object files, -cmain must be used to desig-
| nate the C or PL/I routine as the main entry point in the executable
| file; a COBOL program cannot be the main entry point in an execut-
| able file containing a C or PL/I main. Unpredictable execution
| behavior will occur if this is attempted and no diagnostics are issued.
| Note: -cmain is only required if -host is also specified.
-comprc_ok=n Controls the cob2 behavior on the return code from the compiler. If
the return code returned by the compiler is less than or equal to n,
cob2 continues to the link step, or, in the compile only case, exits with
a zero return code. If the return code returned by the compiler is
greater than n, cob2 exits with the same return code returned by the
compiler.
The default is: -comprc_ok=4.
-Fxxx Use xxx as a configuration file and a stanza rather than the defaults
specified in the /etc/cob2.cfg configuration file. xxx is one of:
config_file:stanza,
config_file, or
:stanza
| 5 In C, a main routine is identified by the function name main(). In PL/I, a main routine is identified by the PROC OPTIONS(MAIN)
| statement.
BINARY(S390)
CHAR(EBCDIC)
COLLSEQ(EBCDIC)
FLOAT(S390)
-main:xxx Make xxx the first file in the files list passed to the linker. The usage
of this option is to make the specified file the main program in the
executable file. xxx must uniquely identify the object file or the
archive library, and the extension must be either .o or .a respec-
tively.
If -main is not specified, the first object, archive library, or source file
specified on the cob2 command will be the first file in the files list
passed to the linker.
If the syntax of -main:xxx is invalid, or xxx is not the filename of an
object or source file processed by cob2, cob2 will terminate.
-o xxx Name the object module xxx (where xxx is any name). If the -o
option is not used, then the name of the object module defaults to
a.out.
-p Instructs the linker to set up the object file produced by the compiler
for AIX profiling6 (command used to evaluate program performance)
with minimum profiling information.
-pg Instructs the linker to set up the object file produced by the compiler
6 For information on prof, the AIX profiling command, see the AIX Commands Reference.
-qxxx Use the option xxx (where xxx is any compiler option) when calling
the compiler. If parentheses are part of the compiler (sub)option, or
several options are specified, they should be included in quotes. For
multiple options, each option should be delimited by a blank or
comma. There should be no spaces between -q and xxx.
For example,
-qoptiona,optionb
or
-q"optiona optionb"
Special Syntax
If you plan to use a shell script to automate your cob2 tasks, a
special syntax is provided for the -qxxx option. Use the following
syntax to prevent the command shell from passing invalid syntax to
cob2:
Use “=” (equal sign) and “:” (colon) rather than “( )” (paren-
theses) to specify compiler suboptions. For example, use
-qBINARY=NATIVE:,ENTRYINT=OPTLINK:
rather than
-qBINARY(NATIVE),ENTRYINT(OPTLINK)
Use “_” (underscore) rather than “ ' ” (apostrophe) where a com-
piler option requires a suboption to be delimited by apostrophes.
For example, use
-qEXIT=INEXIT=_String_,MYMODULE::
rather than
-qEXIT(INEXIT('String',MYMODULE))
Do not use any blanks in the option string.
7 For information on gprof, the AIX graph profiling command, see the AIX Commands Reference.
You can display the options used by cob2 by specifying the -# option. If you are using
the default configuration file, the command cob2 -# abc.cbl displays:
exec: /usr/lpp/cobol/bin/IGYCCOB2 abc.cbl
exec: /usr/bin/ld -bpT:ðx1ððððððð -bpD:ðx2ððððððð -bhalt:5 /lib/crtð.o abc.o
-lcob2s -l/usr/lpp/cobol/lib -lsmrtlite -l/usr/lpp/som/lib -lsomtk -liconv -lc
-lm
The cob2.cfg configuration file allows you to specify a number of items, such as default
options and the location of the compiler and library. If you edit or display (using the cat
command) /etc/cob2.cfg, you will see:
DEFLT: compiler1 = /usr/lpp/cobol/bin/IGYCCOB2
This is the line that specifies the COBOL compiler to use. Other lines in the file specify
the linker and various options.
If you tailor the configuration file, you should check your modifications by issuing the
cob2 command with the -# option to display the effect of your changes.
In /etc/cob2.cfg are sections beginning cob2:, cob2_r:, and so on. These sections
are referred to as stanzas. You can list the supplied configuration files with the
command ls /usr/bin/cob2\. You will see /usr/bin/cob2, /usr/bin/cob2_r, and so
on. The file /usr/bin/cob2_r is linked to /usr/bin/cob2. Commands cob2 and cob2_r
execute the same module, but cob2 uses the cob2 stanza and cob2_r uses the cob2_r
stanza. You can add your own stanza, for example mycob2, and use it by specifying it
with the -F option:
cob2 myfile.cbl -F/u/myhome/myconfig.cfg:mycob2
Or you can define a mycob2 command:
ln -s /usr/bin/cob2 /u/myhome/mycob2
mycob2 myfile.cbl -F/u/myhome/myconfig
Or you can add mystanza to /etc/cob2.cfg and:
ln -s /usr/bin/cob2 mycob2
mycob2 myfile.cbl
Note that whatever directory you name in the ln command (such as /u/myhome above)
must be in your PATH.
The items in each stanza are listed in “Stanzas in the Configuration File.” You can
change any of them. For example, to add a library to the list of libraries used by the
linker, change the runlib2 option.
These means of specification are listed in order of precedence. For example, an option
specified using PROCESS overrides every other option specification except for non-
overridable options selected during product installation.
55──┬─CBL─────┬──┬──────────────┬─────────────────────────────────────5%
└─PROCESS─┘ └─options-list─┘
Wherever possible, the message provides specific instructions for correcting the error.
The messages for compilation errors found in your program (ordered by line number)
are displayed near the end of the listing for each program.
A summary of all errors found during compilation is displayed near the bottom of your
listing. Each message issued by the compiler is of the following form:
Format
nnnnnn IGYppxxxx-l message-text
nnnnnn
The number of the source statement of the last line the compiler was processing.
Source statement numbers are listed on the source printout of your program. If
you specified the NUMBER option at compile time, these are your original source
program numbers. If you specified NONUMBER, the numbers are those generated
by the compiler.
IGY
The prefix that identifies this message as coming from the COBOL compiler.
pp Two characters that identify which phase of the compiler discovered the error. As
an application programmer, you can ignore this information, unless you are diag-
nosing a suspected compiler error. In that case, contact IBM for support.
xxxx
A 4-digit number that identifies the error message.
message-text
The message text itself which, in the case of an error message, is a short explana-
tion of the condition that caused the error.
Remember, if you used the FLAG option to suppress messages, there might be addi-
tional errors in your program.
In the following example, the part of the statement that caused the message to be
issued is enclosed in quotes.
..
.
LineID Message code Message text
2 IGYDSððð9-E "PROGRAM" should not begin in area "A". It was processed as if found in area "B".
2 IGYDS1ð89-S "PROGRAM" was invalid. Scanning was resumed at the next area "A" item, level-number,
or the start of the next clause.
2 IGYDSðð17-E "ID" should begin in area "A". It was processed as if found in area "A".
2 IGYDS1ðð3-E A "PROGRAM-ID" paragraph was not found. Program name "CBLPGMð1" was assumed.
2 IGYDS11ð2-E Expected "DIVISION", but found "ALONGPRO". "DIVISION" was assumed before "ALONGPRO".
2 IGYDS1ð89-S "ALONGPRO" was invalid. Scanning was resumed at the next area "A" item, level-number,
or the start of the next clause.
2 IGYDS1ðð3-E A "PROGRAM-ID" paragraph was not found. Program name "CBLPGMð2" was assumed.
3 IGYPSðð17-E "PROCEDURE" should begin in area "A". It was processed as if found in area "A".
34 IGYSCð137-E Program-name "ALONGPRO" did not match the name of any open program. The "END PROGRAM" statement
was assumed to have ended program "CBLPGMð2".
34 IGYSCð136-E Program "CBLPGMð1" required an "END PROGRAM" statement at this point in the program.
An "END PROGRAM" statement was assumed.
Messages Total Informational Warning Error Severe Terminating
Printed: 12 1ð 2
..
.
Although you should try to correct errors, it is not necessary to fix all of them. A
W-level or I-level message can be left in a program without much risk, and you might
decide that the recoding and compilation needed to remove the error are not worth the
effort. On the other hand, S-level and E-level errors indicate probable program failure
and should be corrected.
U-level errors are in a class by themselves. Here, you have no choice but to correct
the error, because the compiler is forced to end early and does not produce complete
object code and listing. In contrast with the four lower levels of errors, a U-level error
might not result from a mistake in the source program. It could come from a flaw in the
compiler itself, or in the operating system.
After correcting the errors in your source program, re-compile the program. If this
second compilation is successful, go on to the link-editing step. If the compiler still
finds problems, repeat the above procedure until only informational messages are
returned.
The listing that is produced includes messages from other IBM COBOL platforms, such
as OS/2, Windows, OS/390, and VM. Some messages do not apply to AIX.
If your program uses an environment variable name to assign a value to a system file
name, set the environment variable before typing the command which executes the
program.
If the run-time routines detect an error, they send a message to the error unit. Error
messages show what routine caused the error.
If run-time messages are abbreviated or incomplete, one or both of the following envi-
ronment variables might be incorrectly set:
LANG
NLSPATH
If a run-time error is severe, AIX creates a core file (that is, a file named core in the
current directory). You can use the COBOL Set for AIX debugger to examine the state
of the program at the time of the error. If the program was compiled with the -g option,
then the debugger will show symbolic and line number information. To use the
debugger to examine a core file, type the command xldb -co xxx, where xxx is the
name of your program. For more information, click on the word “help” when the xldb
screen appears.
Compiler options are listed and described in alphabetical order in “Compiler Option
Descriptions” on page 149. Compiler-directing statements are listed at the end of this
chapter, on page 187.
Performance Considerations
The CHAR, DYNAM, FLOAT, OPTIMIZE, SSRANGE, TEST, and TRUNC compiler options
can all affect run-time performance.
ADATA
55──┬─ADATA───┬───────────────────────────────────────────────────────5%
└─NOADATA─┘
Use ADATA when you want the compiler to create a SYSADATA file, which contains
records of additional compilation information. This information is used by other tools,
which will set ADATA ON for their use. The size of this file generally grows with the size
of the associated program.
You cannot specify ADATA in a PROCESS (CBL) statement; it can be specified only:
On invocation of the compiler using an option list
As a command option
As an installation default
See “EXIT” on page 157 for information on using SYSADATA with your compiler-exit
module.
ANALYZE
55──┬─ANALYZE───┬─────────────────────────────────────────────────────5%
└─NOANALYZE─┘
Use ANALYZE when you want the compiler to check the syntax of embedded SQL and
CICS statements in addition to native COBOL statements.
You can specify the ADATA option with this option to create a SYSADATA file for later
analysis by program understanding tools, such as the Year 2000 tool included with the
Professional Edition of IBM VisualAge COBOL.
This option may be set as the installation default option or as a compiler invocation
option, but may not be set on a CBL or PROCESS statement.
The specification of the ANALYZE option forces the handling of the following character
strings as reserved words:
CICS
EXEC
END-EXEC
SQL
APOST
See “QUOTE/APOST” on page 173.
BINARY
55──BINARY(─┬─NATIVE─┬─)──────────────────────────────────────────────5%
├─S37ð───┤
└─S39ð───┘
CALLINT
55──CALLINT(─┬─SYSTEM───┬──┬─────────────────────┬─)──────────────────5%
├─OPTLINK──┤ └─,──┬─DESC─────────┬─┘
├─FAR16────┤ ├─DESCRIPTOR───┤
├─PASCAL16─┤ ├─NODESC───────┤
└─CDECL────┘ └─NODESCRIPTOR─┘
CHAR
55──CHAR(─┬─NATIVE─┬─)────────────────────────────────────────────────5%
├─EBCDIC─┤
└─S39ð───┘
Specify CHAR(NATIVE) to use the native character representation format of the platform.
For COBOL Set for AIX, this is ASCII.
CHAR(EBCDIC) and CHAR(S390) are synonymous and indicate that DISPLAY data items
are in the data representation of System/390 (EBCDIC).
– Zoned decimal data (numeric picture with USAGE DISPLAY) and external
floating point data. For example, zoned decimal PIC S9 value “1” is treated as
X'C1' instead of X'31'.
Group items
Group items are treated similar to USAGE DISPLAY items. Note that any USAGE
clause on a group item applies to the elementary items within the group and not to
the group itself.
Hexadecimal literals are assumed to represent EBCDIC characters if the literals are
assigned to, or compared with, character data. For example, X'C1' will compare equal
to an alphanumeric item with the value “A.”
Figure 43 summarizes the conversion and the collating sequence applicable based on
the types of data (ASCII, EBCDIC) and the COLLSEQ option in effect when PROGRAM
COLLATING SEQUENCE is not specified. If it is specified, the source specification has
precedence over the compiler option specification.
For additional information about the CHAR compiler option, see Appendix B,
“System/390 Host Data Type Considerations” on page 469.
COLLSEQ
55──COLLSEQ(─┬─NATIVE─┬─)─────────────────────────────────────────────5%
├─EBCDIC─┤
└─BIN────┘
Specify COLLSEQ(EBCDIC) to use the EBCDIC collating sequence rather than the ASCII
collating sequence.
Specify COLLSEQ(BIN) to use the hex values of the characters; the locale setting has no
effect. This setting will give better execution-time performance.
COMPILE
55──┬─COMPILE────────────┬────────────────────────────────────────────5%
├─NOCOMPILE──────────┤
└─NOCOMPILE(─┬─W─┬─)─┘
├─E─┤
└─S─┘
Use the COMPILE option only if you want to force full compilation even in the presence
of serious errors. All diagnostics and object code will be generated. Do not try to run
the object code generated if the compilation resulted in serious errors—the results
could be unpredictable or an abnormal termination could occur.
Use NOCOMPILE without any suboption to request a syntax check (only diagnostics
produced, no object code).
Use NOCOMPILE with W, E, or S for conditional full compilation. For meanings of error
codes, see “Compiler-Detected Errors and Messages” on page 142. Full compilation
(diagnosis and object code) will stop when the compiler finds an error of the level you
specify (or higher), and only syntax checking will continue.
CURRENCY
55──┬─CURRENCY(literal)─┬─────────────────────────────────────────────5%
└─NOCURRENCY────────┘
The default currency symbol is the dollar sign ($). You can use the CURRENCY option
to provide an alternate default currency symbol to be used for the COBOL program.
To change the default currency symbol, use the CURRENCY(literal) option where literal
is a valid COBOL non-numeric literal (including a hex literal) representing a one-byte,
printable ASCII character that must not be any of the following:
Digits zero (0) through nine (9)
Uppercase alphabetic characters A B C D P R S V X Z
Lowercase alphabetic characters a through z
The space
Special characters * + - / , . ; ( ) " =
A figurative constant
The uppercase alphabetic character G, if the COBOL program defines an MBCS
item with the PICTURE symbol G; the PICTURE clause will be invalid for that MBCS
item because the symbol G is considered to be a currency symbol in the PICTURE
clause.
The uppercase alphabetic character N, if the COBOL program defines an MBCS
item with the PICTURE symbol N; the PICTURE clause will be invalid for that MBCS
item because the symbol N is considered to be a currency symbol in the PICTURE
clause.
The uppercase alphabetic character E, if the COBOL program defines an external
floating-point item; the PICTURE clause will be invalid for the external floating-point
item because the symbol E is considered to be a currency symbol in the PICTURE
clause.
You can use the CURRENCY option as an alternative to the CURRENCY SIGN clause for
selecting the currency symbol you will use in the PICTURE clause of a COBOL program.
When both the CURRENCY option and the CURRENCY SIGN clause are used in a
program, the symbol coded in the CURRENCY SIGN clause will be considered the cur-
rency symbol in a PICTURE clause when that symbol is used.
When the NOCURRENCY option is in effect and you omit the CURRENCY SIGN clause,
the dollar sign ($) is used as the PICTURE symbol for the currency sign.
Delimiter Note: The CURRENCY option literal can be delimited by either the quote or
the apostrophe, regardless of the QUOTE|APOST compiler setting.
| DATEPROC
|
| 55──┬─DATEPROC─┬────────────────┬──┬──────────────────────────────────5%
| │ └─(─┬─FLAG───┬─)─┘ │
| │ └─NOFLAG─┘ │
| └─NODATEPROC───────────────────┘
| Use the DATEPROC option to enable the millennium language extensions of the COBOL
| compiler. For information on using these extensions, see Chapter 29, “Using the
| Millennium Language Extensions” on page 446.
| DATEPROC(FLAG)
| With DATEPROC(FLAG), the millennium language extensions are enabled, and the
| compiler will produce a diagnostic message wherever a language element uses or
| is affected by the extensions. The message will usually be an information-level or
| warning-level message that identifies statements that involve date-sensitive proc-
| essing. Additional messages may be generated that identify errors or possible
| inconsistencies in the date constructs. For information on how to reduce these
| diagnostic messages, see “Eliminating Warning-Level Messages” on page 460.
| Production of diagnostic messges, and their appearance in or after the source
| listing, is subject to the setting of the FLAG compiler option.
| DATEPROC(NOFLAG)
| With DATEPROC(NOFLAG), the millennium language extensions are in effect, but
| the compiler will not produce any related messages unless there are errors or
| inconsistencies in the COBOL source.
| NODATEPROC
| NODATEPROC indicates that the extensions are not enabled for this compilation
| unit. This affects date-related program constructs as follows:
| The DATE FORMAT clause is syntax-checked, but has no effect on the exe-
| cution of the program.
| The DATEVAL and UNDATE intrinsic functions have no effect. That is, the
| value returned by the intrinsic function is exactly the same as the value of the
| argument.
| Notes:
| 1. Specification of the DATEPROC option requires that the NOCMPR2 option is also
| used.
| 2. NODATEPROC conforms to the COBOL 85 Standard.
DYNAM
55──┬─DYNAM───┬───────────────────────────────────────────────────────5%
└─NODYNAM─┘
Use DYNAM to cause non-nested, separately compiled programs invoked through the
CALL literal statement to be loaded (for CALL) and deleted (for CANCEL) dynamically at
run time. CALL identifier statements always result in a run-time load of the target
program and are not impacted by this option.
The condition for the ON EXCEPTION phrase can occur for a CALL statement using the
literal name only when the DYNAM option is in effect.
With NODYNAM, the target program name is resolved through the linker.
ENTRYINT
55──ENTRYINT(─┬─SYSTEM──┬─)───────────────────────────────────────────5%
├─OPTLINK─┤
└─CDECL───┘
EXIT
┌──
────────────────────────────┐
55──┬─EXIT(──6┬─INEXIT(─┬───────┬─mod1)──┬┴─)─┬────────────────────────5%
│ │ └─str1,─┘ │ │
│ ├─NOINEXIT─────────────────┤ │
│ ├─LIBEXIT(─┬───────┬─mod2)─┤ │
│ │ └─str2,─┘ │ │
│ ├─NOLIBEXIT────────────────┤ │
│ ├─PRTEXIT(─┬───────┬─mod3)─┤ │
│ │ └─str3,─┘ │ │
│ ├─NOPRTEXIT────────────────┤ │
│ ├─ADEXIT(─┬───────┬─mod4)──┤ │
│ │ └─str4,─┘ │ │
│ └─NOADEXIT─────────────────┘ │
└─NOEXIT─────────────────────────────────┘
If you specify the EXIT option without providing at least one suboption, NOEXIT will be in
effect. The suboptions can be specified in any order, separated by either commas or
spaces. If you specify both the positive and negative form of a suboption
(INEXIT|NOINEXT, LIBEXIT|NOLIBEXIT, PRTEXIT|NOPRTEXIT, OR ADEXIT|NOADEXIT), the
form specified last takes effect. If you specify the same suboption more than one time,
the one specified last takes effect.
Use the EXIT option to allow the compiler to accept user-supplied modules in place of
SYSIN, SYSLIB (or copy library), and SYSPRINT. When creating your EXIT module,
ensure that the module is linked as a DLL module before you run it with the COBOL
compiler. EXIT modules are invoked with the system linkage convention of the platform.
For SYSADATA, the ADEXIT suboption provides a module that will be called for each
SYSADATA record immediately after the record has been written out to the file.
INEXIT(['str1',]mod1)
The compiler reads source code from a user-supplied load module (where mod1 is
the module name), instead of SYSIN.
LIBEXIT(['str2',]mod2)
The compiler obtains copy code from a user-supplied load module (where mod2 is
the module name), instead of library-name or SYSLIB. For use with either COPY or
BASIS statements.
PRTEXIT(['str3',]mod3)
The compiler passes printer-destined output to the user-supplied load module
(where mod3 is the module name), instead of SYSPRINT.
ADEXIT(['str4',]mod4)
The compiler passes the SYSADATA output to the user-supplied load module
(where mod4 is the module name).
The module names mod1, mod2, mod3, and mod4, can refer to the same module.
The suboptions 'str1', 'str2', 'str3', and 'str4', are character strings that are passed to the
load module. These strings are optional; if you use them, they can be up to 64 charac-
ters in length and must be enclosed in apostrophes. Any character is allowed, but
included apostrophes must be doubled, and lowercase characters are folded to upper-
case.
LL string
where LL is a halfword (on a halfword boundary) containing the length of the string.
See Figure 44 on page 159 for the location of the character string in the parameter list.
The user-exit work area is four fullwords, residing on a fullword boundary, that is initial-
ized to binary zeroes before the first exit routine is invoked. The address of the work
area is passed to the exit module in a parameter list. After initialization, the compiler
makes no further reference to the work area. So, you will need to establish your own
conventions for using the work area if more than one exit is active during the compila-
tion. For example, the INEXIT module uses the first word in the work area, the LIBEXIT
module uses the second word, and the PRTEXIT module uses the third word.
Using INEXIT
When INEXIT is specified, the compiler loads the exit module (mod1) during initializa-
tion, and invokes the module using the OPEN operation code (op code). This allows the
module to prepare its source for processing and then pass the status of the OPEN
request back to the compiler. Subsequently, each time the compiler requires a source
statement, the exit module is invoked with the GET op code. The exit module then
returns either the address and length of the next statement or the end-of-data indication
(if no more source statements exist). When end-of-data is presented, the compiler
invokes the exit module with the CLOSE op code so that the module can release any
resources that are related to its input.
The compiler uses a parameter list to communicate with the exit module. The param-
eter list consists of 10 fullwords. The return code, data length, and data parameters
are placed by the exit module for return to the compiler; and the other items are passed
from the compiler to the exit module.
Figure 44 on page 159 shows the contents of the parameter list and a description of
each item.
Using LIBEXIT
When LIBEXIT is specified, the compiler loads the exit module (mod2) during initializa-
tion. Calls are made to the module by the compiler to obtain copy text whenever
COPY or BASIS statements are encountered.
Use LIB: If LIBEXIT is specified, the LIB compiler option must be in effect.
The first call invokes the module with an OPEN op code. This allows the module to
prepare the specified library-name for processing. The OPEN op code is also issued
the first time a new library-name is specified. The exit module returns the status of the
OPEN request to the compiler by passing a return code.
Once the exit invoked with the OPEN op code returns, the exit module is then invoked
with a FIND op code. The exit module establishes positioning at the requested text-
name (or basis-name) in the specified library-name. This becomes the “active copy
source”. When positioning is complete, the exit module passes an appropriate return
code to the compiler.
The compiler then invokes the exit module with a GET op code, and the exit module
passes the compiler the length and address of the record to be copied from the active
copy source. The GET operation is repeated until the end-of-data indicator is passed to
the compiler.
When end-of-data is presented, the compiler will issue a CLOSE request so that the exit
module can release any resources related to its input.
Nested COPY Statements: Any record from the active copy source can contain a
COPY statement. (However, nested COPY statements cannot contain the REPLACING
phrase, and a COPY statement with the REPLACING phrase cannot contain nested copy
statements.) When a valid nested COPY statement is encountered, the compiler issues
a request based on the following:
If the requested library-name from the nested COPY statement was not previously
opened, the compiler invokes the exit module with an OPEN op code, followed by a
FIND for the new text-name.
If the requested library-name is already open, the compiler issues the FIND op
code for the new requested text-name (an OPEN is not issued here).
The compiler does not allow recursive calls to text-name. That is, a COPY member can
be named only once in a set of nested COPY statements until the end-of-data for that
copy member is reached.
When the exit module receives the OPEN or FIND request, it should push its control
information concerning the active copy source onto a stack and then complete the
requested action (OPEN or FIND). The newly requested text-name (or basis-name) now
becomes the active copy source.
Processing continues in the normal manner with a series of GET requests until the end-
of-data indicator is passed to the compiler.
At end-of-data for the nested active copy source, the exit module should pop its control
information from the stack. The next request from the compiler will be a FIND, so that
the exit module can reestablish positioning at the previous active copy source.
The compiler now invokes the exit module with a GET request, and the exit module
must pass the same record that was passed previously from this copy source. The
compiler verifies that the same record was passed, and then the processing continues
with GET requests until the end-of-data indicator is passed.
Figure 44 on page 159 shows the contents of the parameter list used for LIBEXIT and a
description of each item.
Using PRTEXIT
When PRTEXIT is specified, the compiler loads the exit module (mod3) during initializa-
tion. The exit module is used in place of the SYSPRINT data set.
The compiler invokes the module using the OPEN operation code (op code). This
allows the module to prepare its output destination for processing and then pass the
status of the OPEN request back to the compiler. Subsequently, each time the compiler
has a line to be printed, the exit module is invoked with the PUT op code. The compiler
supplies the address and length of the record that is to be printed, and the exit module
returns the status of the PUT request to the compiler by a return code. The first byte of
the record to be printed contains an ANSI printer control character.
Before the compilation is ended, the compiler invokes the exit module with the CLOSE
op code so that the module can release any resources that are related to its output
destination.
Figure 44 on page 159 shows the contents of the parameter list used for PRTEXIT and
a description of each item.
Using ADEXIT
When ADEXIT is specified, the compiler loads the exit module (mod4) during initialization.
The exit module is called for each record written to the SYSADATA data set.
The compiler invokes the module using the OPEN operation code (op code). This
allows the module to prepare for processing and then pass the status of the OPEN
request back to the compiler. Subsequently, each time the compiler has written a
SYSADATA record, the exit module is invoked with the PUT op code. The compiler sup-
plies the address and length of the SYSADATA record, and the exit module returns the
status of the PUT request to the compiler by a return code.
Before the compilation is ended, the compiler invokes the exit module with the CLOSE
op code so that the module can release any resources.
Figure 44 on page 159 shows the contents of the parameter list used for ADEXIT and a
description of each item.
FLAG
55──┬─FLAG(x─┬────┬─)─┬───────────────────────────────────────────────5%
│ └─,y─┘ │
└─NOFLAG──────────┘
Use FLAG(x) to produce diagnostic messages for errors of a severity level x or above at
the end of the source listing.
Use FLAG(x,y) to produce diagnostic messages for errors of severity level x or above at
the end of the source listing, with error messages of severity y and above to be
embedded directly in the source listing. The severity coded for y must not be lower
than the severity coded for x. To use FLAG(x,y), you must also specify the SOURCE
compiler option.
Error messages in the source listing are set off by embedding the statement number in
an arrow that points to the message code. The message code is then followed by the
message text. For example:
==ððð413==> IGYPS2121-S " WS-DATE " was not defined as a data-name. ...
With FLAG(x,y) selected, messages of severity y and above will be embedded in the
listing following the line that caused the message. (Refer to the notes below for
exceptions.)
Use NOFLAG to suppress error flagging. NOFLAG will not suppress error messages for
compiler options.
Embedded Messages:
1. Specifying embedded level-U messages is accepted, but will not produce any mes-
sages in the source. Embedding a level-U message is not recommended.
2. The FLAG option does not affect diagnostic messages produced before the com-
piler options are processed.
3. Diagnostic messages produced during processing of compiler options, CBL and
PROCESS statements, or BASIS, COPY, and REPLACE statements, are never
embedded in the source listing. All such messages appear at the beginning of the
compiler output.
4. Messages produced during processing of the *CONTROL (*CBL) statement are not
embedded in the source listing.
FLAGSTD
55──┬─FLAGSTD(x─┬────┬──┬────┬─)─┬────────────────────────────────────5%
│ └─yy─┘ └─,O─┘ │
└─NOFLAGSTD──────────────────┘
I Language elements that are not from the minimum or the intermediate subset are
to be flagged as “nonconforming standard”.
H The high subset is being used and elements will not be flagged by subset. And,
elements in the IBM extension category will be flagged as “non-conforming
Standard, IBM extension”.
Use FLAGSTD to get informational messages about the COBOL 85 Standard elements
included in your program. You can specify any of the following items for flagging:
A selected Federal Information Processing Standard (FIPS) COBOL subset
Any of the optional modules
Obsolete language elements
Any combination of subset and optional modules
Any combination of subset and obsolete elements
IBM extensions (these are flagged any time FLAGSTD is specified and are identified
as “non-conforming non-standard”)
This includes the new language syntax for object-oriented COBOL and for
| improved interoperability, the PGMNAME(MIXED) compiler option, and the
| Millennium Language Extensions.
The informational messages appear in the source program listing and contain the fol-
lowing information:
Identify the element as “obsolete”, “non-conforming standard”, or “non-conforming
non-standard” (a language element that is both obsolete and non-conforming is
flagged as obsolete only).
Identify the clause, statement, or header that contains the element.
Identify the source program line and beginning location of the clause, statement, or
header that contains the element.
Identify the subset or optional module to which the element belongs.
In the following example, the line number and column where a flagged clause, state-
ment, or header occurred are shown, as well as the message code and text. At the
bottom is a summary of the total of the flagged items and their type.
3 1 1 1
FLOAT
55──FLOAT(─┬─NATIVE─┬─)───────────────────────────────────────────────5%
├─HEX────┤
└─S39ð───┘
Specify FLOAT(NATIVE) to use the native floating point data representation format of the
platform. For COBOL Set for AIX, this is the IEEE format.
FLOAT(HEX) and FLOAT(S390) are synonymous and indicate that COMP-1 and COMP-2
data items are represented consistently with System/390 (that is, in the hex floating
point format):
Hex floating point values are converted to IEEE format prior to any arithmetic oper-
ations (computations or comparisons).
IEEE floating point values are converted to hex format prior to being stored in
floating point data fields.
Assignment to a floating point item is done by converting the source floating point
data (for example, external floating point) to hex floating point as necessary.
| Object-oriented programs: Do not specify FLOAT(S390) in object-oriented programs.
For additional information about the FLOAT compiler option, see Appendix B,
“System/390 Host Data Type Considerations” on page 469.
IDLGEN
55──┬─IDLGEN───┬──────────────────────────────────────────────────────5%
└─NOIDLGEN─┘
Use the IDLGEN option to indicate whether SOM Interface Definition Language (IDL)
should be generated for COBOL class definitions contained in the COBOL source file.
Use IDLGEN to request that in addition to the normal compile of the COBOL source file,
IDL definitions for classes defined in the file are generated.
The IDL file has the same name as the compiler source file, with the file extension IDL.
For example, IDL file generated for myfile.cbl would be myfile.idl. The IDL file is
written to the directory from which cob2 was run.
When a class definition includes references to other classes (such as on the INHERITS
or METACLASS IS phrases, or typed object references as method parameters) that are
defined in separate source files, the generated IDL will contain include statements for
the IDL files of the referenced classes. The COBOL compiler will attempt to obtain the
file name (referred to as the filestem in the SOM documentation) for a referenced class
from the SOM interface repository (IR). If the referenced class does not have an IR
entry, then the external class-name of the referenced class is assumed as the filestem.
An include is then generated of the form: #include <filestem..idl> This may be
adequate for classes where external class-names are the same as the original source
file name. However, in many cases this include statement will need to either be
updated to reflect the correct filestem or preferably, the entire IDL file should be re-
generated after the missing definition has been added to the IR.
When a COBOL source file contains more than one class definition (batch compile) and
the IDLGEN option is used, the COBOL class definitions must be sequenced in an
appropriate order within the source file. The generated IDL for such a batch compile
will contain multiple class interfaces with the IDL interfaces in the same order as the
COBOL classes were defined in the COBOL source file. The SOM IDL compiler
requires that interfaces be defined before they are referenced, so if there are refer-
ences between the classes in the COBOL batch compile, the referenced classes must
precede the referencing classes in the COBOL source file.
The IDL generated for the same COBOL class by the IBM COBOL compiler on OS/390,
OS/2, Windows, and AIX might differ; hence, the IDL should be regenerated for the
target platform rather than ported between platforms. For example, the procedure-
pointer data type in COBOL for OS/390 & VM is an 8-byte data item that does not map
to any native IDL type, hence a COBOL specific mapping is used. On OS/2, Windows,
and AIX, procedure-pointers are 4-byte data items that map to IDL pointers. Another
example is that on OS/390 or AIX, a PIC S9(8) BINARY data item maps naturally to an
IDL “long” type, while on OS/2 and Windows, the same data item may map either to an
IDL long or to a COBOL-specific data type that emulates System/390 binary format,
depending on the compilation options used.
No PROCESS: The IDLGEN options cannot be specified on the PROCESS(CBL) state-
ment.
See Chapter 13, “Writing Object-Oriented Programs” on page 222 and Chapter 15,
“Using SOM IDL-Based Class Libraries” on page 275 for more information on IDL and
SOM.
LIB
55──┬─LIB───┬─────────────────────────────────────────────────────────5%
└─NOLIB─┘
If your program uses COPY, BASIS, or REPLACE statements, the LIB compiler option
must be in effect.
For more information, see the discussion of the library-name user-defined variable on
page 129.
In addition, for COPY and BASIS statements, you need to define the library or libraries
from which the compiler can take the copied code:
If the library-name is specified with a user-defined word (not a literal), you must set
the corresponding environment variable to point to the desired directory/path for the
copy file.
If the library-name is omitted for a COPY statement, the path to be searched can be
specified via the -Ixxx option on the cob2 command.
If the library-name is specified with a literal, the literal value is treated as the actual
path name.
LINECOUNT
55──LINECOUNT(nnn)────────────────────────────────────────────────────5%
Abbreviations are: LC
Use LINECOUNT(nnn) to specify the number of lines to be printed on each page of the
compilation listing, or use LINECOUNT(0) to suppress pagination.
If you specify LINECOUNT(0), no page ejects are generated in the compilation listing.
The compiler uses three lines of nnn for titles. For example, if you specify
LINECOUNT(60), 57 lines of source code are printed on each page of the output listing.
LIST
55──┬─LIST───┬────────────────────────────────────────────────────────5%
└─NOLIST─┘
If you want to limit the assembler listing output, use *CONTROL LIST or NOLIST state-
ments in your PROCEDURE DIVISION. Your source statements following a *CONTROL
NOLIST are not included in the listing until a *CONTROL LIST statement switches the
output back to normal LIST format. For a description of the *CONTROL (*CBL) statement,
see IBM COBOL Language Reference.
For information on using LIST output, see “Data Map Listing” on page 211.
MAP
55──┬─MAP───┬─────────────────────────────────────────────────────────5%
└─NOMAP─┘
Use MAP to produce a listing of the items you defined in the DATA DIVISION. Map
output includes:
DATA DIVISION map
Global tables
Literal pools
Nested program structure map, and program attributes
Size of the program's Working-Storage
If you want to limit the MAP output, use *CONTROL MAP or NOMAP statements in the
PROCEDURE DIVISION. Source statements following a *CONTROL NOMAP are not
included in the listing until a *CONTROL MAP statement switches the output back to
normal MAP format. For a description of the *CONTROL (*CBL) statement, see the IBM
COBOL Language Reference.
For information on using LIST output, see “Data Map Listing” on page 211.
By selecting the MAP option, you can also print an embedded MAP report in the source
code listing. The condensed MAP information is printed to the right of data-name defi-
nitions in the FILE SECTION, WORKING-STORAGE SECTION, and LINKAGE SECTION of
the DATA DIVISION.
| MAXMEM
|
| 55──MAXMEM(size)──────────────────────────────────────────────────────5%
| Use MAXMEM in conjunction with OPTIMIZE to limit the amount of memory used by the
| compiler for local tables of specific, memory-intensive optimizations to size kilobytes. If
| that memory is insufficient for a particular optimization, the scope of the optimization is
| reduced.
| Notes:
| 1. The limit set by MAXMEM is the amount of memory for specific optimizations, and
| not for the compiler as a whole. Tables required during the entire compilation
| process are not affected or included in this limit.
| 2. Setting a large limit has no negative effect on the compilation of source files where
| the compiler needs less memory.
| 3. Limiting the scope of optimization does not necessarily mean that the resulting
| program will be slower, only that the compiler may finish before finding all opportu-
| nities to increase performance.
| 4. Increasing the limit does not necessarily mean that the resulting program will be
| faster, only that the compiler is better able to find opportunities to increase perform-
| ance if they exist.
| Depending on the source file being compiled, the size of the subprograms in the
| source, the machine configuration, and the workload on the system, setting the limit too
| high might lead to page space exhaustion. In particular, specifying MAXMEM(-1) allows
| the compiler to try and use an unlimited amount of storage, which in the worst case can
| exhaust the resources of even the most well-equipped machine.
NUMBER
55──┬─NUMBER───┬──────────────────────────────────────────────────────5%
└─NONUMBER─┘
Use NUMBER if you have line numbers in your source code and want those numbers to
be used in error messages and MAP, LIST, and XREF listings.
If you request NUMBER, columns 1 through 6 are checked to make sure that they
contain only numbers, and the sequence is checked according to numeric collating
sequence. (In contrast, SEQUENCE checks them according to ASCII collating
sequence.) When a line number is found to be out of sequence, the compiler assigns
to it a line number with a value one number higher than the line number of the pre-
ceding statement. Sequence-checking continues with the next statement, based on the
newly assigned value of the previous line.
If you use COPY statements and NUMBER is in effect, be sure that your source program
line numbers and the COPY member line numbers are coordinated.
Use NONUMBER if you do not have line numbers in your source code, or if you want the
compiler to ignore the line numbers you do have in your source code. With NONUMBER
in effect, the compiler generates line numbers for your source statements and uses
those numbers as references in listings.
OPTIMIZE
55──┬─OPTIMIZE─┬──────────────┬──┬────────────────────────────────────5%
│ └─(─┬─STD──┬─)─┘ │
│ └─FULL─┘ │
└─NOOPTIMIZE─────────────────┘
Use OPTIMIZE to reduce the run time of your object program; optimization might also
reduce the amount of storage your object program uses. Optimizations performed
include the propagation of constants, instruction scheduling, and the elimination of com-
putations whose results are never used. Because OPTIMIZE increases compile time,
and can change the order of statements in your program, it should not be used when
debugging.
The FULL suboption requests that in addition to the optimizations performed under
OPT(STD), that the compiler discard unreferenced data items from the DATA DIVISION,
and suppress generation of code to initialize these data items to their VALUE clauses. If
the OPT(FULL) and MAP options are specified, then a BL number of XXXX in the data
map information indicates that the data item was discarded.
Recomendation: Use OPTIMIZE(FULL) for database applications; it can make a huge
performace improvement, because unused constants included by the associated COPY
statements will be eliminated.
However:
Do not use OPT(FULL) if your programs depend on making use of unused data
items. Two common ways this has been done in the past are:
1. A technique sometimes used in OS/VS COBOL programs is to place an unrefer-
enced table after a referenced table and use out-of-range subscripts on the first
table to access the second table. To see if your programs have this problem, use
the SSRANGE compiler option with the CHECK(ON) run-time option. To work around
this problem, use the ability of COBOL to code large tables and use just one table.
2. The second technique utilizing unused data items is to place eyecatcher data items
in the WORKING-STORAGE section to identify the beginning and end of the program
data, or to mark a copy of a program for a library tool that uses the data to identify
a version of a program. To solve this problem, initialize these items with PROCE-
DURE DIVISION statements rather than VALUE clauses. With this method, the com-
piler will consider these items as used, and will not delete them.
The OPTIMIZE option is turned off in the case of a severe-level error or higher. The
OPTIMIZE and TEST options are mutually exclusive; if you use both, OPTIMIZE will be
ignored.
PGMNAME
55──PGMNAME(─┬─MIXED─┬─)──────────────────────────────────────────────5%
└─UPPER─┘
For compatibility with IBM COBOL for OS/390 & VM, LONGMIXED and LONGUPPER are
also supported.
The PGMNAME option controls the handling of names used in the following contexts:
Program names defined in the PROGRAM-ID paragraph.
Program entry point names on the ENTRY statement.
Program name references in:
– CALL statements
– CANCEL statements
– SET procedure-pointer TO ENTRY statements
PGMNAME(UPPER)
With PGMNAME(UPPER), program names that are specified in the PROGRAM-ID para-
graph as COBOL user-defined words must follow the normal COBOL rules for forming
a user-defined word:
The program name can be up to 30 characters in length.
All the characters used in the name must be alphabetic, digits, or the hyphen.
At least one character must be alphabetic.
The hyphen cannot be used as the first or last character.
External program names are processed with alphabetic characters folded to upper
case.
PGMNAME(MIXED)
With PGMNAME(MIXED), program names are processed as is, without truncation, trans-
lation, or folding to upper case.
With PGMNAME(MIXED), all program name definitions must be specified using the literal
format of the program name in the PROGRAM-ID paragraph or ENTRY statement.
PROFILE
55──┬─PROFILE───┬─────────────────────────────────────────────────────5%
└─NOPROFILE─┘
PROFILE instructs the compiler to prepare the object file for AIX profiling (prof utility,
used for performance analysis). This option should be used with the -p option of the
cob2 command (see “Compiling and Linking Programs” on page 135).
QUOTE/APOST
55──┬─QUOTE─┬─────────────────────────────────────────────────────────5%
└─APOST─┘
Use QUOTE if you want the figurative constant [ALL] QUOTE or [ALL] QUOTES to repre-
sent one or more quotation mark (") characters. QUOTE conforms to the COBOL 85
Standard.
Use APOST if you want the figurative constant [ALL] QUOTE or [ALL] QUOTES to repre-
sent one or more apostrophe (') characters.
Delimiters: Either quotes or apostrophes can be used as literal delimiters, regardless
of whether the APOST or QUOTE option is in effect. The delimiter character used as the
opening delimiter for a literal must be used as the closing delimiter for that literal.
SEPOBJ
55──┬─SEPOBJ───┬──────────────────────────────────────────────────────5%
└─NOSEPOBJ─┘
The option specifies whether or not each of the outermost COBOL programs in a batch
compilation is to be generated as a separate object file rather than a single object file.
Batch Compilation
When multiple outer-most programs (non-nested programs) are compiled with a single
invocation of the compiler (batch compiled), how many separate files are produced for
the object program output of the batch compilation varies on the compiler option
SEPOBJ.
Assume that the COBOL source file, pgm.cbl, contains three outer-most COBOL pro-
grams named pgm1, pgm2, and pgm3. The following figures illustrate whether the object
program output is generated as one (with NOSEPOBJ) or three (with SEPOBJ) files.
pgm.cbl
┌───────────────────┐
│ │
│ PROGRAM-ID. pgm1. │ pgm.o
│ ... │ ┌───────┐
│ END PROGRAM pgm1. │ │ │
├───────────────────┤ │ pgm1 │
│ │ │ │
│ PROGRAM-ID. pgm2. │ ├───────┤
│ ... │ ────────────5 │ pgm2 │
│ END PROGRAM pgm2. │ │ │
├───────────────────┤ ├───────┤
│ │ │ pgm3 │
│ PROGRAM-ID. pgm3. │ │ │
│ ... │ └───────┘
│ END PROGRAM pgm3. │
└───────────────────┘
pgm.cbl pgm.o
┌───────────────────┐ ┌──────┐
│ │ ┌───────5 │ pgm1 │
│ PROGRAM-ID. pgm1. │ │ │ │
│ ... │ │ └──────┘
│ END PROGRAM pgm1. │ │
├───────────────────┤ │ pgm2.o
│ │ │ ┌──────┐
│ PROGRAM-ID. pgm2. │ ─────┼───────5 │ pgm2 │
│ ... │ │ │ │
│ END PROGRAM pgm2. │ │ └──────┘
├───────────────────┤ │
│ │ │ pgm3.o
│ PROGRAM-ID. pgm3. │ │ ┌──────┐
│ ... │ └───────5 │ pgm3 │
│ END PROGRAM pgm3. │ │ │
└───────────────────┘ └──────┘
Considerations:
1. The SEPOBJ option is required to conform to the ANSI COBOL standard where
pgm2 or pgm3 in the above example is called via CALL identifier from another
program.
2. If the NOSEPOBJ option is in effect, the name(s) of object module file(s) are named
with the name of the source file with .o, .OBJ, and/or .LIB extensions. If the
SEPOBJ option is in effect, the names of the object files (except for the first one)
are based on the PROGRAM-ID name with the .o or .OBJ extension.
3. The programs called via CALL identifier must be referred to by the names of the
object files (rather than the PROGRAM ID names) where PROGRAM ID and the
object file name do not match.
You are responsible for giving the object file a valid file name for the platform and the
file system.
SEQUENCE
55──┬─SEQUENCE───┬────────────────────────────────────────────────────5%
└─NOSEQUENCE─┘
When you use SEQUENCE, the compiler examines columns 1 through 6 of your source
statements to check that the statements are arranged in ascending order according to
their ASCII collating sequence. The compiler issues a diagnostic message if any state-
ments are not in ascending sequence (source statements with blanks in columns 1
through 6 do not participate in this sequence check and do not result in messages).
If you use COPY statements and SEQUENCE is in effect, be sure that your source
program sequence fields and the copy member sequence fields are coordinated.
If you use NUMBER and SEQUENCE, the sequence is checked according to numeric,
rather than ASCII, collating sequence.
SIZE
55──SIZE(─┬─nnnnn─┬─)─────────────────────────────────────────────────5%
└─nnnK──┘
Abbreviations are: SZ
Use SIZE to indicate the amount of main storage available for compilation (where 1K =
1024 bytes decimal).
SOURCE
55──┬─SOURCE───┬──────────────────────────────────────────────────────5%
└─NOSOURCE─┘
Use SOURCE to get a listing of your source program. This listing will include any state-
ments embedded by PROCESS or COPY statements.
SOURCE must be specified if you want embedded messages in the source listing.
Use NOSOURCE to suppress the source code from the compiler output listing.
If you want to limit the SOURCE output, use *CONTROL SOURCE or NOSOURCE state-
ments in your PROCEDURE DIVISION. Your source statements following a *CONTROL
NOSOURCE are not included in the listing at all, unless a *CONTROL SOURCE statement
switches the output back to normal SOURCE format. For a description of the *CONTROL
(*CBL) statement, see IBM COBOL Language Reference.
For information on using LIST output, see “Data Map Listing” on page 211.
SPACE
55──SPACE(─┬─1─┬─)────────────────────────────────────────────────────5%
├─2─┤
└─3─┘
Use SPACE to select single, double, or triple spacing in your source code listing.
SPACE has meaning only when the SOURCE compiler option is in effect.
SPILL
55────SPILL(n)────────────────────────────────────────────────────────5%
This option specifies the register spill area size. If the program being compiled is very
complex or large, this option may be required. The spill size, n, is any integer between
96 and 32704 and designates the number of kilobytes set aside for the register spill
area.
SQL
55──SQL(─┬─"─┬─suboptions for DB2 SQL─┬─"─┬─)─────────────────────────5%
└─'─┘ └─'─┘
Use this option when you have SQL statements embedded in your COBOL source. It
allows you to specify options to be used in handling the SQL statements in your
program and is required if the suboption string, which gives SQL options, is to be speci-
fied explicitly to DB2.
The syntax shown can be used on either the CBL or PROCESS statements. If the SQL
option is given on the cob2 command, only ' is allowed for the string delimiter:
-q"SQL('options')".
See Chapter 20, “Programming for a DB2 Environment” on page 354 for more informa-
tion.
SSRANGE
55──┬─SSRANGE───┬─────────────────────────────────────────────────────5%
└─NOSSRANGE─┘
Use SSRANGE to generate code that checks if subscripts (including ALL subscripts) or
indexes try to reference an area outside the region of the table. Each subscript or
index is not individually checked for validity; rather, the effective address is checked to
ensure that it does not cause a reference outside the region of the table. Variable-
length items will also be checked to ensure that the reference is within their maximum
defined length.
TERMINAL
55──┬─TERMINAL───┬────────────────────────────────────────────────────5%
└─NOTERMINAL─┘
TEST
55──┬─TEST───┬────────────────────────────────────────────────────────5%
└─NOTEST─┘
Use TEST to produce object code that contains symbol and statement information that
enables the debugger to perform symbolic source-level debugging.
Use NOTEST if you do not want to generate object code with debugging information.
Programs compiled with NOTEST execute with the debugger, but there is limited debug-
ging support.
The TEST option will be turned off if you use the WITH DEBUGGING MODE clause. The
TEST option will appear in the list of options, but a diagnostic message will be issued to
advise you that because of the conflict, TEST will not be in effect.
THREAD
55──┬─THREAD───┬──────────────────────────────────────────────────────5%
└─NOTHREAD─┘
THREAD indicates if the COBOL application is to be enabled for execution in a run unit
with multiple threads. All programs within a run unit must be compiled with either the
THREAD or NOTHREAD option.
When the THREAD option is in effect, the following language elements are not sup-
ported. If encountered, they are diagnosed as errors:
STOP RUN
ALTER statement
DEBUG-ITEM special register
GO TO statement without procedure-name
RERUN
STOP literal statement
Segmentation module
USE FOR DEBUGGING statement
WITH DEBUGGING MODE clause
INITIAL phrase in PROGRAM-ID paragraph
Notes:
1. RERUN is flagged as an error with THREAD, but is accepted as a comment with
NOTHREAD.
| 2. With THREAD, you must use the cob2_r command to compile your program. See
| “Compiling and Linking Programs” on page 135 for details.
See Chapter 24, “Preparing COBOL Programs for Multithreading” on page 397 for a
discussion of COBOL support for multithreading.
TRUNC
55──TRUNC(─┬─STD─┬─)──────────────────────────────────────────────────5%
├─OPT─┤
└─BIN─┘
TRUNC has no effect on COMP-5 data items; COMP-5 items are handled as if
TRUNC(BIN) were in effect, regardless of the TRUNC option specified.
TRUNC(STD)
Use TRUNC(STD) to control the way arithmetic fields are truncated during MOVE
and arithmetic operations. TRUNC(STD) applies only to USAGE BINARY receiving
fields in MOVE statements and arithmetic expressions. When TRUNC(STD) is in
effect, the final result of an arithmetic expression, or the sending field in the MOVE
statement, is truncated to the number of digits in the PICTURE clause of the BINARY
receiving field.
TRUNC(OPT)
TRUNC(OPT) is a performance option. When TRUNC(OPT) is specified, the compiler
assumes that the data conforms to PICTURE and USAGE specifications of the
USAGE BINARY receiving fields in MOVE statements and arithmetic expressions.
The results are manipulated in the most optimal way, either truncating to the
number of digits in the PICTURE clause, or to the size of the binary field in storage
(halfword, fullword, or doubleword).
Caution: You should use the TRUNC(OPT) option only if you are sure that the data
being moved into the binary areas will not have a value with larger precision than
that defined by the PICTURE clause for the binary item. Otherwise, unpredictable
results might occur. This truncation is performed in the most efficient manner pos-
sible; therefore, the results will be dependent on the particular code sequence gen-
erated. It is not possible to predict the truncation without seeing the code
sequence generated for a particular statement.
TRUNC(BIN)
The TRUNC(BIN) option applies to all COBOL language that processes USAGE
BINARY data. When TRUNC(BIN) is in effect:
TRUNC Example 1
ð1 BIN-VAR PIC 99 USAGE BINARY.
.
.
MOVE 123451 to BIN-VAR
A halfword of storage is allocated for BIN-VAR. The result of this MOVE statement if the
program is compiled with the TRUNC(STD) option is 51; the field is truncated to conform
to the PICTURE clause.
If the program is compiled with the TRUNC(BIN) option, the result of the MOVE statement
is -7621. The reason for the unusual looking answer is that nonzero high-order digits
were truncated. Here, the generated code sequence would merely move the lower
halfword quantity X'E23B' to the receiver. Because the new truncated value over-
flowed into the sign bit of the binary halfword, the value becomes a negative number.
This MOVE statement should not be compiled with the TRUNC(OPT) option because
123451 has greater precision than the PICTURE clause for BIN-VAR. If TRUNC(OPT) was
used, however, the results again would be -7621. This is because the best perform-
ance was gained by not doing a decimal truncation.
Assumption: The preceding example assumes that the BINARY(S390) option is in
effect.
TRUNC Example 2
ð1 BIN-VAR PIC 9(6) USAGE BINARY
.
.
MOVE 1234567891 to BIN-VAR
When TRUNC(STD) is specified, the sending data is truncated to six integer digits to
conform to the PICTURE clause of the BINARY receiver.
When TRUNC(OPT) is specified, the compiler assumes the sending data is not larger
than the PICTURE clause precision of the BINARY receiver. The most efficient code
sequence in this case performed truncation as if TRUNC(STD) had been specified.
When TRUNC(BIN) is specified, no truncation occurs because all of the sending data will
fit into the binary fullword allocated for BIN-VAR.
Assumption: The preceding example assumes that the BINARY(S390) option is in
effect.
TYPECHK
55──┬─TYPECHK───┬─────────────────────────────────────────────────────5%
└─NOTYPECHK─┘
Use TYPECHK to have the compiler enforce the rules for object-oriented type checking,
and generate diagnostics for any violations.
The type conformance requirements are covered in the IBM COBOL Language Refer-
ence under the appropriate language elements. Type checking requirements include:
The method being invoked on an INVOKE statement must be supported by the
class of the referenced object.
Method parameters on an INVOKE and the corresponding method PROCEDURE
DIVISION USING must conform.
When TYPECHK is specified, there must be entries in the SOM Interface Repository (IR)
for each class that is referenced in the COBOL source being compiled.
For COBOL classes, these IR entries can be created by using the COBOL IDLGEN
option (see “IDLGEN” on page 165) when compiling the class definitions, to create an
IDL file that describes the interface of the COBOL class. Compile the IDL using the
SOM compiler with its "ir" emitter.
Note that if the COBOL program references classes that are provided by the SOM
product itself (such as the SOMObject class), then the pre-generated IR for these
classes that is provided as part of the OS/390 SOMobjects product may be used to
verify that the COBOL usage conforms to the class interfaces.
See Chapter 14, “Using System Object Model (SOM)” on page 269, SOMobjects
Developer's Toolkit User's Guide, and SOMobjects Developer's Toolkit Programmer's
Reference Manual (available online) for further details on interface repositories, SOM,
and type checking.
VBREF
55──┬─VBREF───┬───────────────────────────────────────────────────────5%
└─NOVBREF─┘
Use VBREF to get a cross-reference among all verb types used in the source program
and the line numbers in which they are used. VBREF also produces a summary of how
many times each verb was used in the program.
WORD
55──┬─WORD(xxxx)─┬────────────────────────────────────────────────────5%
└─NOWORD─────┘
xxxx specifies the ending characters of the name of the reserved-word table (IGYCxxxx)
to be used in your compilation. IGYC are the first 4 standard characters of the name,
and xxxx can be 1 to 4 characters in length.
IBM COBOL provides an alternate reserved-word table (IGYCCICS) specifically for CICS
applications. It is set up to flag COBOL words not supported under CICS with an error
message. If you want to use this CICS reserved-word table during your compilation,
specify the compiler option WORD(CICS). For information on the CICS reserved-word
table, refer to “CICS has a Special Reserved Word Table” on page 359.
If you want to use this NOOO reserved-word table during your compilation, specify the
compiler option WORD(NOOO).
| WSCLEAR
|
| 55──┬─WSCLEAR───┬─────────────────────────────────────────────────────5%
| └─NOWSCLEAR─┘
| Use WSCLEAR to clear your program's working storage to binary zeros when the
| program is initialized. The storage is cleared before any VALUE clauses are applied.
| If you use WSCLEAR and you are concerned about the size or performance of the
| object program, then you should also use OPTIMIZE(FULL). This instructs the compiler
| to eliminate all unreferenced data items from the DATA DIVISION, which will speed up
| the initialization process.
XREF
55──┬─XREF─┬───────────────┬──┬───────────────────────────────────────5%
│ └─(─┬─SHORT─┬─)─┘ │
│ └─FULL──┘ │
└─NOXREF──────────────────┘
Use XREF to get a sorted cross-reference listing. Names are listed in the order of the
collating sequence indicated by the locale setting. This applies whether the names are
in single-byte characters or contain multi-byte characters (such as DBCS).
Also included is a section listing all the program names that are referenced in your
program, and the line number where they are defined. External program names are
identified as such.
If you use XREF and SOURCE, cross-reference information will also be printed on the
same line as the original source in the listing. Line number references or other informa-
tion, will appear on the right hand side of the listing page. On the right of source lines
that reference intrinsic functions, the letters 'IFN' will appear with the line numbers of
the location where the function's arguments are defined. Information included in the
embedded references lets you know if an identifier is undefined or defined more than
once (UND or DUP will be printed); if an item is implicitly defined (IMP), such as special
registers or figurative constants; and if a program name is external (EXT).
If you use XREF and NOSOURCE, you'll get only the sorted cross-reference listing.
XREF(SHORT) will print only the explicitly referenced variables in the cross-reference
listing. XREF(SHORT) applies to MBCS data names and procedure-names as well as
ASCII names.
Observe:
1. Group names used in a MOVE CORRESPONDING statement are in the XREF listing.
In addition, the elementary names in those groups are also listed.
2. In the data-name XREF listing, line numbers preceded by the letter “M” indicate that
the data item is explicitly modified by a statement on that line.
3. XREF listings take additional storage.
See Chapter 12, “Debugging Techniques” on page 197 for sample listings.
| YEARWINDOW
|
| 55──YEARWINDOW──(base-year)───────────────────────────────────────────5%
| Abbreviation is: YW
| Use the YEARWINDOW option to specify the first year of the 100-year window (the
| century window) to be applied to windowed date field processing by the COBOL com-
| piler. For information on using windowed date fields, see Chapter 29, “Using the
| Millennium Language Extensions” on page 446.
| base-year represents the first year of the 100-year window, and must be specified as
| one of the following:
| An unsigned decimal number between 1900 and 1999.
| This specifies the starting year of a fixed window. For example,
| YEARWINDOW(1930) indicates a century window of 1930-2029.
| cates that the first year of the century window is 80 years before the current year
| at the time the program is run.
| Notes:
| 1. The YEARWINDOW option has no effect unless the DATEPROC option is also in
| effect.
| 2. At run time, two conditions must be true:
| The century window must have its beginning year in the 1900s
| The current year must lie within the century window for the compilation unit
| For example, running a program in 1998 with YEARWINDOW(-99) violates the first
| condition, and would result in a run-time error.
ZWB
55──┬─ZWB───┬─────────────────────────────────────────────────────────5%
└─NOZWB─┘
With ZWB, the compiler removes the sign from a signed external decimal (DISPLAY)
field when comparing this field to an alphanumeric elementary field during execution.
If the external decimal item is a scaled item (contains the symbol 'P' in its PICTURE
character-string), its use in comparisons is not affected by ZWB. Such items always
have their sign removed before the comparison is made to the alphanumeric field.
ZWB affects how the program runs; the same COBOL source program can give different
results, depending on the option setting.
Use NOZWB if you want to test input numeric fields for SPACES.
Compiler-Directing Statements
Several statements help you to direct the compilation of your program. For the defi-
nition of these statements, see IBM COBOL Language Reference.
BASIS statement
This extended source program library statement provides a complete COBOL
program as the source for a compilation.
>>CALLINTERFACE statement
This compiler directing statement specifies the interface convention for calls,
including whether argument descriptors are to be generated. The convention spec-
ified using >>CALLINT is in effect until another >>CALLINT specification is made.
>>CALLINT can be used only in the PROCEDURE DIVISION.
The syntax and usage of the >>CALLINT statement is similar to the CALLINT com-
piler option. Exceptions are:
See the IBM COBOL Language Reference for the full syntax. See “CALLINT” on
page 150 for details of the option form.
If you specify >>CALLINT with no suboptions, the call convention used is determined
by the CALLINT compiler option. For example, if PROG1 is an IBM C program
whose default call interface convention is _OPTLINK, or it is a COBOL program
compiled with the ENTRYINT(OPTLINK) option, use the >>CALLINT directive to
change the interface for this call only:
>>CALLINT OPTLINK DESC
CALL "PROG1" USING PARM1 PARM2.
>>CALLINT
CALL "PROG2" USING PARM1.
Descriptor Only: The >>CALLINT statement is treated as a comment except for
the forms:
>>CALLINT SYSTEM DESCRIPTOR
>>CALLINT DESCRIPTOR
The >>CALLINT statement can be specified anywhere that a COBOL procedure
statement can be specified. For example, the following is valid COBOL syntax:
MOVE 3 TO
>>CALLINTERFACE SYSTEM
RETURN-CODE.
The effect of >>CALLINT is limited to the current program. A nested program or a
program compiled in the same batch inherits the calling convention specified with
the CALLINT compiler option, not the >>CALLINT compiler directive.
If you are writing a routine that is to be called with >>CALLINT SYSTEM,
DESCRIPTOR, this is the argument-passing mechanism:
COPY statement
55──COPY─┬─text-name─┬──┬──────────────┬──────────────────────────5%
└─literal-1─┘ ├─library-name─┤
└─literal-2────┘
library-name
If you specify library-name as a literal (literal-2), it is treated as the actual path.
If you specify library-name with a user-defined word, the name is used as an
environment variable and the value of the environment variable is used for the
path to locate the COPY text. To specify multiple path names, delimit them by
using a colon (:) or a semicolon (;).
If you don't specify library-name, the path used is as described under text-
name.
text-name
The processing of text-name as a user-defined word depends on whether the
environment variable corresponding to the text-name is set. If the the environ-
ment variable is set, the value of the environment variable is used as the file
name, and possibly the path name, for the copybook.
A text-name is treated as both the path and file name if:
For example,
COPY "/mycpylib/..."
If the environment variable corresponding to the text-name is not set, the copy
text is searched for as the following names:
-I option
For other cases (when neither a library-name nor text-name indicates the
path), the path searched is dependent on the -I option. For details, see
“Options Supported by cob2” on page 136.
To have COPY A be equivalent to COPY A OF MYLIB specify -I$MYLIB.
Based on the above rules, COPY "/X/Y" will be searched in the root directory,
while COPY "X/Y" will be searched in the current directory.
COPY A OF SYSLIB is equivalent to COPY A. The -I option does not impact
COPY statements with explicit library-name qualifications besides those with
the library name of SYSLIB.
You can access OS/390 files from AIX using NFS (Network File System), which
allows OS/390 files to be accessed using an AIX pathname. However, note that it
converts the path separator to “.” to follow OS/390 naming conventions. You
should keep this in mind when assigning values to your environment variables to
ensure proper name formation. For example, these settings
export MYCOPY=(MYMEMBER)
export MYLIB=M/MYFILE/MYPDS
See the AIX System Management Guide: Communications and Networks for
details on associating a local directory with a remote target.
For more information on the COPY statement, see the discussion of the COPY
statement in the IBM COBOL Language Reference.
DELETE statement
This extended source library statement removes COBOL statements from the
BASIS source program.
EJECT statement
This compiler-directing statement specifies that the next source statement is to be
printed at the top of the next page.
ENTER statement
The compiler handles this statement as a comment.
INSERT statement
This library statement adds COBOL statements to the BASIS source program.
REPLACE statement
This statement is used to replace source program text.
SKIP1/2/3 statement
These statements indicate lines to be skipped in the source listing.
TITLE statement
This statement specifies that a title (header) be printed at the top of each page of
the source listing. (See “Changing Header of Source Listing” on page 13.)
USE statement
The USE statement provides declaratives to specify the following:
Error-handling procedures—EXCEPTION/ERROR
Debugging lines and sections—DEBUGGING
Syntax
Syntax of the run-time options follows. See “Definitions of COBOL Environment
Variables” on page 129 to see where to specify them.
CHECK
CHECK flags checking errors in an application. In COBOL, index, subscript, and refer-
ence modification ranges are checking errors.
┌─ON──┐
55──CHECK──(──┼─────┼──)──────────────────────────────────────────────5%
└─OFF─┘
Abbreviation is: CH
ON
Specifies that run-time checking is performed.
OFF
Specifies that run-time checking is not performed.
Usage Note
CHECK(ON) has no effect if NOSSRANGE was in effect at compile time.
Performance Consideration
If your COBOL program was compiled with SSRANGE, and you are not testing or
debugging an application, performance improves when you specify CHECK(OFF).
DEBUG
DEBUG specifies whether the COBOL debugging sections specified by the USE FOR
DEBUGGING declarative are active.
┌─DEBUG───┐
55──┴─NODEBUG─┴───────────────────────────────────────────────────────5%
DEBUG
Activates the debugging sections.
NODEBUG
Suppresses the debugging sections.
Performance Consideration
To improve performance, use this option only while debugging.
ERRCOUNT
ERRCOUNT specifies how many conditions of severity 1 (W-level) can occur before the
run-unit terminates abnormally. Any severity 2 (E-level) or higher will result in termi-
nation of the run-unit independent of the ERRCOUNT option.
55──ERRCOUNT──(──┬────────┬──)────────────────────────────────────────5%
└─number─┘
Default: ERRCOUNT(20).
number
The number of severity 1 conditions that can occur while this run-unit is running. If
the number of conditions exceeds number, the run-unit terminates abnormally.
FILESYS
FILESYS specifies the file system used for files for which no explicit file system
selections are made, either through an ASSIGN or an evironment variable. The option
applies to sequential, relative, and indexed files. For details about using FILESYS for
access to CICS files, see “Accessing SFS Data” on page 363.
┌─VSA─┐
55──FILESYS──(──┴─STL─┴──)────────────────────────────────────────────5%
Default is : FILESYS(VSA).
Only the first three characters of the file system identifier are used and the identifier is
case insensitive. For example, the following examples are all valid specifications for
VSAM:
FILESYS(VSA)
FILESYS(vSAM)
FILESYS(vsa)
TRAP
TRAP indicates whether COBOL intercepts exceptions.
┌─ON──┐
55──TRAP──(──┼─────┼──)───────────────────────────────────────────────5%
└─OFF─┘
Default is : TRAP(ON).
Note: If TRAP(OFF) is in effect and you do not supply your own trap handler to handle
exceptional conditions, the conditions will result in a default action by the operating
system. For example, if your program attempts to store into an illegal location, the
default system action is to issue a message and terminate the process.
ON
Activates COBOL interception of exceptions.
OFF
Deactivates COBOL interception of exceptions.
Usage Notes
Use TRAP(OFF) only when you need to analyze a program exception before
COBOL handles it.
When you specify TRAP(OFF) in a non-CICS environment, no exception handlers
are established.
Running with TRAP(OFF) (for exception diagnosis purposes) can cause many side
effects, because COBOL requires TRAP(ON). When you run with TRAP(OFF), you
can get side effects even if you do not encounter a software-raised condition,
program check, or abend. If you do encounter a program check or an abend with
TRAP(OFF) in effect, the following side effects can occur:
UPSI
UPSI sets the eight UPSI switches on or off for applications that use COBOL routines.
55──UPSI──(──┬──────────┬──)──────────────────────────────────────────5%
└─nnnnnnnn─┘
Default is : UPSI(00000000).
nnnnnnnn
n represents one UPSI switch between 0 and 7, the leftmost n representing the
first switch. Each n can either be 0 (off) or 1 (on).
This chapter describes only COBOL source language debugging techniques. The
XLDB Debugger is a graphical debugging tool you will find useful for debugging pro-
grams. For help with the debugger, refer to its online help and information.
The rules for using each of these language features are explained in IBM COBOL Lan-
guage Reference.
For example, to determine whether a particular routine started and finished you might
insert code like this into your program:
DISPLAY "ENTER CHECK PROCEDURE"
.
. (checking procedure routine)
.
DISPLAY "FINISHED CHECK PROCEDURE"
After you are sure that the routine works correctly, you can put asterisks in column 7 of
the DISPLAY statement lines, which converts them to comment lines. Alternatively, you
might put a 'D' in column 7 of your DISPLAY (or any other debugging) statements. If
you include the WITH DEBUGGING MODE clause in the ENVIRONMENT DIVISION, the 'D'
in column 7 will be ignored and the DISPLAY statements will be implemented. Without
the DEBUGGING MODE clause, the 'D' in column 7 makes the statement a comment.
Before you put the program into production, delete all the debugging aids you used and
re-compile the program. The program will run more efficiently and use less storage.
CICS: The DISPLAY statement cannot be used in programs running under CICS.
If the file fails to open for some reason, the appropriate EXCEPTION/ERROR declarative
will be performed. The appropriate declarative might be a specific one for the file or
one provided for the different open attributes—INPUT, OUTPUT, I/O, or EXTEND.
Each USE AFTER STANDARD ERROR statement must be coded in a separate section.
This section(s) must be coded immediately after the DECLARATIVE SECTION keyword of
the PROCEDURE DIVISION. The rules for coding these statements are provided in IBM
COBOL Language Reference.
To use file status keys as a debugging aid, include a test after each I/O statement to
check for a value other than zero in the status key. If the value is other than zero, you
can expect that you will receive an error message. You can use a nonzero value as an
indication that you should look at the way the I/O procedures in the program were
coded. You can also include procedures to correct the error based on the value of the
status key.
The status key values and their associated meanings are described in the IBM COBOL
Language Reference.
You can have either debugging lines or debugging statements or both in your program.
Debugging lines are statements in your program that are identified by a 'D' in column 7.
Debugging statements are the statements coded in the DECLARATIVES SECTION of the
PROCEDURE DIVISION.
To use debugging lines in your program, you must include the WITH DEBUGGING MODE
clause on the SOURCE-COMPUTER line in the ENVIRONMENT DIVISION.
Environment Division
.
.
.
Data Division.
.
.
.
Working-Storage Section.
.
. (other entries your program needs)
.
Main-Program Section.
.
. (source program statements)
.
Perform Some-Routine.
.
. (source program statements)
.
Stop Run.
Some-Routine.
.
. (whatever statements you need in this paragraph)
.
Add 1 To Total.
Some-Routine-End
In Figure 50, the DISPLAY statement coded in the DECLARATIVES SECTION will issue
this message:
Trace For Procedure-Name : Some-Routine 22
every time the procedure SOME-ROUTINE is run. The number at the end of the message,
22, is the value accumulated in the data-item, TOTAL; it shows the number of times
SOME-ROUTINE has been run. The statements in the debugging declarative are per-
formed before the named procedure is run.
Another Use for the DISPLAY Statement: You can also use the DISPLAY statement
technique shown above to trace program execution and show the flow through your
program. You do this by changing the USE FOR DEBUGGING declarative in the DECLAR-
ATIVES SECTION to:
USE FOR DEBUGGING ON ALL PROCEDURES.
and dropping the word TOTAL from the DISPLAY statement. Now, a message will be
displayed before every non-debugging procedure in the outermost program is run.
The FLAG option lets you select the level of error to be diagnosed during compilation
and indicate where the syntax-error messages appear in the listing. Use FLAG(I) or
FLAG(I,I) to be notified of all errors in your program.
Code in the first parameter the lowest severity level of the syntax-error messages to be
issued. You can code in the optional second parameter the lowest level of the syntax
messages to be embedded in the source listing.
If you specify:
I (informational)
You get all the messages. I-level messages generate a return code of zero; RC=0.
W (warning)
You get all the warning messages and those of a higher severity. W-level errors
generate a return code of four; RC=4.
E (error)
You get all error messages and those of a higher severity. E-level errors generate
a return code of eight; RC=8.
S (severe)
You get all severe and U (unrecoverable) messages. S-level errors generate a
return code of twelve; RC=12.
U (unrecoverable)
You get only unrecoverable messages. U-level errors generate a return code of
sixteen; RC=16.
When you specify the second parameter, the syntax-error messages are embedded in
the source listing at the point where the compiler had enough information available to
detect the error. All embedded messages, except those issued by the library compiler
phase, will directly follow the statement to which they refer. The number of the state-
ment containing the error is also included with the message. Embedded messages are
repeated with the rest of the diagnostic messages following the source listing.
202 COBOL Set for AIX Programming Guide
Using Compiler Options for Debugging
Embedded Messages:
1. If NOSOURCE is one of your options, the syntax-error messages are included only
in the list at the end of the listing.
2. U-level errors are not embedded in the source listing, as an error of this severity
terminates the compilation.
For an illustration of how messages identifying syntax errors are imbedded in the
source listing, see Figure 51 on page 203.
Note that some messages in the summary apply to more than one COBOL statement.
DATA VALIDATION AND UPDATE PROGRAM FLAGOUT Date ð2/27/1998 Time 12:26:53 Page 26
LineID PL SL ----+-\A-1-B--+----2----+----3----+----4----+----5----+----6----+----7-|--+----8 Map and Cross Reference
.
.
.
ððð977 /
ððð978 \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
ððð979 \\\ I N I T I A L I Z E P A R A G R A P H \\
ððð98ð \\\ Open files. Accept date, time and format header lines. \\
ððð981 IA469ð\\\ Load location-table. \\
ððð982 \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
ððð983 1ðð-initialize-paragraph.
ððð984 move spaces to ws-transaction-record IMP 339
ððð985 move spaces to ws-commuter-record IMP 315
ððð986 move zeroes to commuter-zipcode IMP 326
ððð987 move zeroes to commuter-home-phone IMP 327
ððð988 move zeroes to commuter-work-phone IMP 328
ððð989 move zeroes to commuter-update-date IMP 332
ððð99ð open input update-transaction-file 2ð3
==ððð99ð==> IGYPS2ð52-S An error was found in the definition of file "LOCATION-FILE". The
reference to this file was discarded.
==ðð1ð11==> IGYPS2121-S "WS-DATE" was not defined as a data-name. The statement was discarded.
==ðð1ð12==> IGYPS2121-S "WS-DATE" was not defined as a data-name. The statement was discarded.
==ðð1ð13==> IGYPS2121-S "WS-TIME" was not defined as a data-name. The statement was discarded.
==ðð1ð14==> IGYPS2121-S "WS-TIME" was not defined as a data-name. The statement was discarded.
192 IGYDS1ð5ð-E File "LOCATION-FILE" contained no data record descriptions. The file definition was discarded.
899 IGYPS2ð52-S An error was found in the definition of file "LOCATION-FILE". The reference to this file was discarded.
1ð11 IGYPS2121-S "WS-DATE" was not defined as a data-name. The statement was discarded.
1ð13 IGYPS2121-S "WS-TIME" was not defined as a data-name. The statement was discarded.
1ð15 IGYPS2ð53-S An error was found in the definition of file "LOCATION-FILE". This input/output statement was discarded.
1ð26 IGYPS2121-S "LOC-CODE" was not defined as a data-name. The statement was discarded.
12ð9 IGYPS2121-S "COMMUTER-SHIFT" was not defined as a data-name. The statement was discarded.
121ð IGYPS2121-S "COMMUTER-HOME-CODE" was not defined as a data-name. The statement was discarded.
1212 IGYPS2121-S "COMMUTER-NAME" was not defined as a data-name. The statement was discarded.
1213 IGYPS2121-S "COMMUTER-INITIALS" was not defined as a data-name. The statement was discarded.
1223 IGYPS2121-S "WS-NUMERIC-DATE" was not defined as a data-name. The statement was discarded.
The following compiler options are suppressed when you use NOCOMPILE without
parameters: LIST, OBJECT, OPTIMIZE, SSRANGE, and TEST.
When you use SEQUENCE, the compiler checks the source statement numbers you
have supplied to see if they are in ascending order. Two asterisks are placed along-
side any statement numbers out of sequence, and the total number of these statements
is printed out as the first line of the diagnostics following the source listing.
You can use the cross-reference listing produced by the XREF option to find out where
a data-name, procedure-name, or program-name was defined and referenced.
The XREF(SHORT) option allows you to control the cross-reference listing by printing
only the explicitly referenced variables.
When you use both the XREF (with FULL or SHORT) and the SOURCE options, you will
get a modified cross-reference printed to the right of the source listing. This embedded
cross-reference gives the line number where the data-name or procedure-name was
defined.
For more information on the XREF option and some example listings, see “A Data-
Name, Procedure-Name, and Program-Name Cross-Reference Listing” on page 216.
For more information on the MAP option, see “Data Map Listing” on page 211.
When the SSRANGE option is specified, checking is not performed until run time and
then, only if both of the following are true:
The COBOL statement containing the indexed, subscripted, variable-length, or
reference-modified data item is actually performed.
The CHECK run-time option is ON at run time.
If any check finds that an address is generated that is outside of the address range of
the group data item containing the referenced data, an error message will be generated
and the program will stop running. The error message identifies the table or identifier
that was being referenced and the line number in the program where the error hap-
pened. Additional information is provided depending on the type of reference that
caused the error.
If all subscripts, indices, or reference modifiers are literals in a given data reference and
they result in a reference outside of the data item, the error will be diagnosed at
compile time, regardless of the setting of the SSRANGE compiler option.
Performance Note: SSRANGE can cause the performance of your program to diminish
somewhat because of the extra overhead needed to check each subscripted or indexed
item.
After reading this section you should be familiar with each type of output; you will know
how to request each type and what kind of information is provided in the output.
The short listing contains diagnostic messages about the compilation, a list of the
options in effect for the program, and statistics about the content of the program.
Figure 52 on page 208 is an example of a short listing.
The listing is explained after Figure 52, and the numbers used in the explanation corre-
spond to those in the figure. (For illustrative purposes, some errors that cause diag-
nostic messages to be issued were deliberately introduced.)
PP 5765-548 IBM COBOL Set for AIX 1.1.ð Date ð2/27/1998 Time 12:26:53 Page 1 .1/
Invocation parameters: .2/
quote
PROCESS(CBL) statements:
CBL FLAG(I,I),MAP,TEST
CBL NONUMBER,QUOTE,SEQ,XREF,VBREF .3/
Options in effect: .4/
ADATA
QUOTE
BINARY(NATIVE)
CALLINT(SYSTEM,NODESCRIPTOR)
CHAR(NATIVE)
NOCICS
COLLSEQ(BINARY)
NOCOMPILE(S)
NOCURRENCY
| NODATEPROC
NODYNAM
ENTRYINT(SYSTEM)
EXIT(NOINEXIT,NOPRTEXIT,NOLIBEXIT,ADEXIT(IWZRMGUX))
FLAG(I,I)
NOFLAGSTD
FLOAT(NATIVE)
NOIDLGEN
LIB
LINECOUNT(6ð)
NOLIST
MAP
NONUMBER
NOOPTIMIZE
PGMNAME(LONGUPPER)
PROBE
NOPROFILE
SEPOBJ
SEQUENCE
SIZE(2ð97152)
SOURCE
SPACE(1)
SQL
NOSSRANGE
TERM
TEST
NOTHREAD
NOTILED
TRUNC(STD)
NOTYPECHK
VBREF
NOWORD
XREF(FULL)
| YEARWINDOW(19ðð)
ZWB
DATA VALIDATION AND UPDATE PROGRAM .5/ SLISTING Date ð2/27/1998 Time 12:26:53 Page 2
IGYDSð139-W Diagnostic messages were issued during processing of compiler options. These messages are
located at the beginning of the listing.
193 IGYDS1ð5ð-E File "LOCATION-FILE" contained no data record descriptions. The file definition was discarded.
889 IGYPS2ð52-S An error was found in the definition of file "LOCATION-FILE". The reference to this file
was discarded.
993 IGYPS2121-S "WS-DATE" was not defined as a data-name. The statement was discarded.
995 IGYPS2121-S "WS-TIME" was not defined as a data-name. The statement was discarded.
997 IGYPS2ð53-S An error was found in the definition of file "LOCATION-FILE". This input/output statement
was discarded.
1ðð8 IGYPS2121-S "LOC-CODE" was not defined as a data-name. The statement was discarded.
1219 IGYPS2121-S "COMMUTER-SHIFT" was not defined as a data-name. The statement was discarded.
122ð IGYPS2121-S "COMMUTER-HOME-CODE" was not defined as a data-name. The statement was discarded.
1222 IGYPS2121-S "COMMUTER-NAME" was not defined as a data-name. The statement was discarded.
1223 IGYPS2121-S "COMMUTER-INITIALS" was not defined as a data-name. The statement was discarded.
1233 IGYPS2121-S "WS-NUMERIC-DATE" was not defined as a data-name. The statement was discarded.
Printed: 21 2 1 18
.1/ COBOL default page header, including compiler level information from the
LVLINFO installation time compiler option.
.2/ Message about options passed to the compiler at compiler invocation. This
message does not appear if no options were passed.
.3/ Options coded in the PROCESS (or CBL) statement.
.4/ Status of options at the start of this compilation.
.5/ Customized page header resulting from the COBOL program TITLE statement.
.6/ Program diagnostics. The first message will refer you to the library phase diag-
nostics, if there were any. Diagnostics for the library phase are always pre-
sented at the beginning of the listing.
.7/ Count of diagnostic messages in this program, grouped by severity level.
.8/ Program statistics for the program SLISTING.
.9/ Program statistics for the compilation unit. When you perform a batch compila-
tion (multiple outermost COBOL programs in a single compilation), the return
code is the highest message severity level for the entire compilation.
Figure 53 shows an example of the output produced by the NUMBER compiler option.
In the portion of the listing shown, the programmer numbered two of the statements out
of sequence.
DATA VALIDATION AND UPDATE PROGRAM .1/ IGYTCARA Date ð2/27/1998 Time 12:26:53 Page 22
LineID PL SL ----+-\A-1-B--+----2----+----3----+----4----+----5----+----6----+----7-|--+----8 Cross-Reference .2/
.3/ .4/ .5/
ð87ððð/\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
ð871ðð\\\ D O M A I N L O G I C \\
ð872ðð\\\ \\
ð873ðð\\\ Initialization. Read and process update transactions until \\
ð874ðð\\\ EOE. Close files and stop run. \\
ð875ðð\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
ð876ðð procedure division.
ð877ðð ððð-do-main-logic.
ð878ðð display "PROGRAM SRCOUT - Beginning"
ð879ðð perform ð5ð-create-vsam-master-file.
ð8815ð display "perform ð5ð-create-vsam-master finished".
ð88151\\ ð88125 perform 1ðð-initialize-paragraph
ð882ðð display "perform 1ðð-initialize-paragraph finished"
ð883ðð read update-transaction-file into ws-transaction-record
ð884ðð at end
1 ð885ðð set transaction-eof to true
ð886ðð end-read
ð887ðð display "READ completed"
ð888ðð perform until transaction-eof
1 ð889ðð display "inside perform until loop"
1 ð89ððð perform 2ðð-edit-update-transaction
1 ð891ðð display "After perform 2ðð-edit "
1 ð892ðð if no-errors
2 ð893ðð perform 3ðð-update-commuter-record
2 ð894ðð display "After perform 3ðð-update "
1 ð8965ð else
ð89651\\ 2 ð896ðð perform 4ðð-print-transaction-errors
2 ð897ðð display "After perform 4ðð-errors "
1 ð898ðð end-if
1 ð899ðð perform 41ð-re-initialize-fields
1 ð9ðððð display "After perform 41ð-reinitialize"
1 ð9ð1ðð read update-transaction-file into ws-transaction-record
1 ð9ð2ðð at end
2 ð9ð3ðð set transaction-eof to true
1 ð9ð4ðð end-read
1 ð9ð5ðð display "After '2nd READ' "
ð9ð6ðð end-perform
.1/ Customized page header resulting from the COBOL program TITLE statement.
.2/ The scale line labels Area A, Area B, and source code column numbers.
.3/ Source code line number assigned by compiler.
.4/ Program (PL) and statement (SL) nesting level.
.5/ Columns 1 through 6 of program (the sequence number area).
DATA VALIDATION AND UPDATE PROGRAM IGYTCARA Date ð2/27/1998 Time 12:26:53 Page 22
.1/
Data Definition Attribute codes (rightmost column) have the following meanings:
D = Object of OCCURS DEPENDING G = GLOBAL LSEQ= ORGANIZATION LINE SEQUENTIAL
E = EXTERNAL O = Has OCCURS clause SEQ= ORGANIZATION SEQUENTIAL
VLO=Variably Located Origin OG= Group has own length definition INDX= ORGANIZATION INDEXED
VL= Variably Located R = REDEFINES REL= ORGANIZATION RELATIVE
When both XREF data and an embedded MAP summary exist on the same line, the
embedded MAP summary is printed first.
...
ððð221 IA162ð ð1 print-record pic x(121). 121
..
.
ððð227 Working-storage section.
ððð228 ð1 Working-storage-for-EMBMAP pic x. 1
ððð229
ððð23ð 77 comp-code pic S9999 comp. 2
ððð231 77 ws-type pic x(3) value spaces. 3
ððð232
ððð233
ððð234 ð1 i-f-status-area. 2
ððð235 ð5 i-f-file-status pic x(2). 2(ððððððð)
ððð236 88 i-o-successful value zeroes. IMP
ððð237
ððð238
ððð239 ð1 status-area. 8
ððð24ð ð5 commuter-file-status pic x(2). .3/ 2(ððððððð)
ððð241 88 i-o-okay value zeroes. IMP
ððð242 ð5 commuter-vsam-status. 6(ðððððð2)
ððð243 1ð vsam-r15-return-code pic 9(2) comp. 2(ðððððð2)
ððð244 1ð vsam-function-code pic 9(1) comp. 2(ðððððð4)
ððð245 1ð vsam-feedback-code pic 9(3) comp. 2(ðððððð6)
ððð246
ððð247 77 update-file-status pic xx. 2
ððð248 77 loccode-file-status pic xx. 2
ððð249 77 updprint-file-status pic xx. 2
..
.
ððð877 procedure division.
ððð878 ððð-do-main-logic.
ððð879 display "PROGRAM EMBMAP - Beginning".
ððð88ð perform ð5ð-create-vsam-master-file. 931
..
.
.1/
The assembler listing will be written to the listing file (a file with the same name as the
source program with the extension “.wlist”).
User-defined words in your program are sorted using the locale that is active. Hence,
the collating sequence will determine the order for the cross-reference listing, including
MBCS words.
Group Names: Group names in a MOVE CORRESPONDING statement are listed in the
XREF listing. The cross-reference listing includes the group names and all the elemen-
tary names involved in the move.
An "M" preceding a data-name reference indicates that the data-name is modified by this reference.
264 ABEND-ITEM1
265 ABEND-ITEM2
347 ADD-CODE . . . . . . . . . . . 1126 1192
381 ADDRESS-ERROR. . . . . . . . . M1156
28ð AREA-CODE. . . . . . . . . . . 1266 1291 1354 1375
382 CITY-ERROR . . . . . . . . . . M1159
.4/
877 ððð-DO-MAIN-LOGIC
943 ð5ð-CREATE-VSAM-MASTER-FILE. . P879
995 1ðð-INITIALIZE-PARAGRAPH . . . P881
1471 11ðð-PRINT-I-F-HEADINGS. . . . P926
1511 12ðð-PRINT-I-F-DATA. . . . . . P928
1573 121ð-GET-MILES-TIME. . . . . . P154ð
1666 122ð-STORE-MILES-TIME. . . . . P1541
1682 123ð-PRINT-SUB-I-F-DATA. . . . P1562
17ð6 124ð-COMPUTE-SUMMARY . . . . . P1563
1ð52 2ðð-EDIT-UPDATE-TRANSACTION. . P89ð
1154 21ð-EDIT-THE-REST. . . . . . . P1145
1189 3ðð-UPDATE-COMMUTER-RECORD . . P893
1237 31ð-FORMAT-COMMUTER-RECORD . . P1194 P12ð9
1258 32ð-PRINT-COMMUTER-RECORD. . . P1195 P12ð6 P1212 P1222
1318 33ð-PRINT-REPORT . . . . . . . P12ð8 P1232 P1286 P131ð P137ð P1395 P1399
1342 4ðð-PRINT-TRANSACTION-ERRORS . P896
The numbers used in explanation below correspond to the numbers in Figure 59.
Cross-Reference of Data-Names
.1/ Line number where the name was defined.
.2/ Data-name.
.3/ Line numbers where the name was used. If an “M” precedes the line
number, the data-item was explicitly modified at the location.
Cross-Reference of Procedure References
.4/ Explanations of the context usage codes for procedure references.
.5/ Line number where the procedure-name is defined.
.6/ Procedure-name.
.7/ Line numbers where the procedure is referenced and the context usage
code for the procedure.
The XREF compiler option also provides you with a sorted cross-reference listing of
program names in your main program.
PP 5765-548 IBM COBOL Set for AIX 1.1.ð Date ð2/27/1998 Time 12:26:53 Page 4
EXTERNAL EXTERNAL1. . . . . . . . . . . 25
2 X. . . . . . . . . . . . . . . 41
12 X1 . . . . . . . . . . . . . . 33 7
2ð X11. . . . . . . . . . . . . . 25 16
27 X12. . . . . . . . . . . . . . 32 17
35 X2 . . . . . . . . . . . . . . 4ð 8
.1/ The line number where the program-name was defined. If the program is
external, the word EXTERNAL will be displayed instead of a definition line
number.
.2/ The program name.
.3/ Line numbers where the program is referenced.
ððð984 1ðð-initialize-paragraph.
ððð985 move spaces to ws-transaction-record IMP 34ð .2/
ððð986 move spaces to ws-commuter-record IMP 316
ððð987 move zeroes to commuter-zipcode IMP 327
ððð988 move zeroes to commuter-home-phone IMP 328
ððð989 move zeroes to commuter-work-phone IMP 329
ððð99ð move zeroes to commuter-update-date IMP 333
ððð991 open input update-transaction-file 2ð4
ððð992 location-file 193
ððð993 i-o commuter-file 181
ððð994 output print-file 217
..
.
ðð1442 11ðð-print-i-f-headings.
ðð1443
ðð1444 open output print-file. 217
ðð1445
ðð1446 move function when-compiled to when-comp. IFN 698 .2/
ðð1447 move when-comp (5:2) to compile-month. 698 64ð
ðð1448 move when-comp (7:2) to compile-day. 698 642
ðð1449 move when-comp (3:2) to compile-year. 698 644
ðð145ð
ðð1451 move function current-date (5:2) to current-month. IFN 649
ðð1452 move function current-date (7:2) to current-day. IFN 651
ðð1453 move function current-date (3:2) to current-year. IFN 653
ðð1454
ðð1455 write print-record from i-f-header-line-1 222 635
ðð1456 after new-page. 138
..
.
.1/ The line number of the definition of the data-name or procedure-name in the
program.
.2/ Special definition symbols. These symbols are:
UND The user-name is undefined
DUP The user-name is defined more than once
IMP An implicitly defined name, such as special registers and figurative con-
stants
IFN An intrinsic function reference
EXT An external reference
* The program-name is unresolved because the NOCOMPILE option is in
effect
To do this, first invoke cob2 with the -# option to see how cob2 invokes the main com-
piler module and what options it passes. For example, given the following cob2 invoca-
tion for compiling PGMNAME.CBL with the IWZRMGUX user exit and linking it:
cob2 -q"EXIT(ADEXIT(IWZRMGUX))" pgmname.cbl
modify the cob2 invocation as follows:
cob2 -# -q"EXIT(ADEXIT(IWZRMGUX))" pgmname.cbl
This is what you'll see:
igyccob2 -q"EXIT(ADEXIT(IWZRMGUX))" pgmname.cbl
ilink /free /nol /pm:vio pgmname.obj
You are interested in the IGYCCOB2 invocation because it is what actually calls your user
exit.
Once classes are determined, the next step is to determine the methods the classes
need to do their work. The order class must provide the following services:
Add items to the order
Delete items from the order
Calculate the cost of the order
Provide the order number to the service representative
Write the final order for later processing
The following methods for the order class meet the above need:
AddItem
Add an item to the order
DeleteItem
Delete an item from the order
CalculateCost
Calculate the cost of the order
GetOrderNumber
Provide the order number
WriteOrder
Write the final order
As you design your class and its methods, you discover the need for the class to keep
some instance data. Typically, an order class needs the following instance data:
Order number
Order date
Number of items in the order
Table of items ordered
Diagrams are very helpful when designing classes and their methods. The following
diagrams depict the order and user interface classes.
┌────────────────┐ ┌──────────────────┐
│Order │ │UserInterface │
│ (order-number) │ │ (action) │
│ (order-date) │ │ (item) │
│ (order-count) │ ├──────────────────┤
│ (order-table) │ │1:ReadUserInput │
├────────────────┤ │2:WriteUserOutput │
│1:AddItem │ │3:WriteUserMessage│
│2:DeleteItem │ └──────────────────┘
│3:CalculateCost │
│4:GetOrderNumber│
│5:WriteOrder │
└────────────────┘
The words in parentheses are instance data and the words after the number and colon
are methods.
The class structure of this object-oriented system is a tree structure. This structure
shows how classes are related to each other and is known as the inheritance hierarchy.
Order and user interface are basic classes, so they inherit from the System Object
Model (SOM) base class, SOMObject.
Multiple Inheritance: All classes in COBOL inherit directly or indirectly from
SOMObject. When multiple inheritance is used, the class structure might not be a
tree—it may be an graph. However, the SOMObject class will always be at the root of
the tree or graph.
The complete class structure for the mail-order catalog system is diagramed as follows:
┌───────────┐
│SOMObject │
├───────────┤
│1:somNew │
│2:somInit │
│3:somFree │
│4:somUninit│
│5: ... │
└────┬──────┘
┌─────────┴──────────┐
┌────────┴───────┐ ┌────────┴─────────┐
│Order │ │UserInterface │
│ (order-number) │ │ (action) │
│ (order-date) │ │ (item) │
│ (order-count) │ ├──────────────────┤
│ (order-table) │ │1:ReadUserInput │
├────────────────┤ │2:WriteUserOutput │
│1:AddItem │ │3:WriteUserMessage│
│2:DeleteItem │ └──────────────────┘
│3:CalculateCost │
│4:GetOrderNumber│
│5:WriteOrder │
└────────────────┘
More Methods: SOMObject has many methods other than the four listed here. See
SOMobjects Developer's Toolkit User's Guide and SOMobjects Developer's Toolkit Pro-
grammer's Reference Manual for a complete description of all the SOM methods.
CLASS-ID Paragraph
Use the CLASS-ID paragraph to:
Name a class.
In the example above, Order is the class name.
Specify the System Object Model (SOM) base class or user-written class from
which this class inherits its characteristics.
In the example above, INHERITS SOMObject indicates Order inherits its basic char-
acteristics from the base SOM class SOMObject.
Name a metaclass.
Discussed in “Writing a Metaclass Definition” on page 258.
A class CONFIGURATION SECTION can consist of the same entries as a program CON-
FIGURATION SECTION, except the INPUT-OUTPUT SECTION. (See “CONFIGURATION
SECTION” on page 13.)
REPOSITORY Paragraph
The REPOSITORY paragraph declares to the compiler that the specified user-defined
word is a class name and optionally relates the class name to an external class name
in the SOM interface repository. You must specify any class name you explicitly refer-
ence in your class definition in the REPOSITORY paragraph. For example:
SOM base classes.
In the example above, CLASS SOMObject IS 'SOMObject' indicates what you are
calling SOMObject in your COBOL program is also called SOMObject in the SOM
interface repository. All SOM names are mixed-case, so SOMObject spelled in
mixed-case is required to properly handle SOM case sensitivity.
User-written classes from which your class is inheriting.
Discussed in “Writing a Subclass Definition” on page 242.
Metaclass to which your class belongs.
Discussed in “Writing a Metaclass Definition” on page 258.
Any class referenced in methods introduced by the class.
You may optionally include the name of the class you are defining. If you do not
include the name of your class, it is treated as all upper-case regardless of how you
typed it on the CLASS-ID. In the example above, Order is stored in the SOM interface
repository in mixed-case.
Data Division.
Working-Storage Section.
ð1 order-number PIC 9(5).
ð1 order-date PIC X(8).
ð1 order-count PIC 99.
ð1 order-table.
ð2 order-entry OCCURS 1ð TIMES.
ð3 order-item PIC X(5).
WORKING-STORAGE SECTION
A class WORKING-STORAGE SECTION describes instance data that is statically allocated
when the instance is created and exists until the instance is freed. By default, the data
is global to all the methods introduced by the class. Instance data in a COBOL class is
private. Thus, it cannot be referenced directly by any other class or subclass. See
“Special Methods” on page 231 for an example of how to share instance data in
COBOL.
Exceptions:
1. You cannot use the VALUE clause to initialize the data.
Class instance data is initialized by overriding the 'somInit' method. See “somInit”
on page 231 for an example using 'somInit'.
Level-88 Note: You can have 88 level numbers with the VALUE clause.
2. You cannot use the EXTERNAL attribute.
3. You can use the GLOBAL attribute, but it has no effect.
DATA DIVISION.
WORKING-STORAGE SECTION.
\
\ Instance data for UserInterface class
\
ð1 uif-action PIC X(1ð).
88 uif-add VALUE 'AddItem'.
88 uif-delete VALUE 'DeleteItem'.
88 uif-quit VALUE 'Quit'.
ð1 uif-item PIC X(5).
PROCEDURE DIVISION.
\
\ method definitions in here
\
END CLASS UserInterface.
METHOD-ID Paragraph
Use the METHOD-ID paragraph to name the method. In the example above, WriteOrder
is the method name. Other methods or programs use this name to invoke the method.
Method Override
Occasionally, a class defines a method whose name exists in a superclass. In this
case, the superclass method must be overridden with the OVERRIDE clause on the
METHOD-ID. System Object Model (SOM) provides two methods designed to be over-
ridden. These SOM methods allow you to initialize instance data when an instance is
created and save instance data when an instance is freed. The methods are called
'somInit' and 'somUninit' respectively. If you wish to override 'somInit', the IDENTIFICA-
TION DIVISION is coded as follows:
Identification Division. Required
Method-Id. "somInit" Override. Required
WORKING-STORAGE SECTION
A single copy of the data defined in the method WORKING-STORAGE SECTION is
allocated when the run-unit begins and persists in its last-used state until the run-
unit terminates. The same single copy of the WORKING-STORAGE data is used
whenever the method is invoked, regardless of the invoking object.
If the VALUE clause is specified, the data item is initialized to the value on the first
invocation of the method. The EXTERNAL clause may be specified for method
WORKING-STORAGE data items (see “Sharing Data Using the EXTERNAL Clause”
on page 346).
A method WORKING-STORAGE SECTION is similar to a program
WORKING-STORAGE SECTION except the GLOBAL attribute has no effect.
If the same data item is defined in both the class DATA DIVISION and the method DATA
DIVISION, a reference in the method to the data name refers to the data item in the
method DATA DIVISION. The method DATA DIVISION takes precedence.
The EXIT METHOD statement returns control to the invoking program or method.
GOBACK has the same effect as EXIT METHOD. If the RETURNING clause is specified
when the method is invoked, the EXIT METHOD or GOBACK returns the value of the data
item to the invoking program or method. STOP RUN MAY be specified in a method;
however, it terminates the run-unit.
An implicit EXIT METHOD is generated as the last statement of every method PROCE-
DURE DIVISION.
All COBOL statements that can be coded in a program PROCEDURE DIVISION can be
coded in a method PROCEDURE DIVISION except:
EXIT PROGRAM
ENTRY statements
The following obsolete elements of ANSI COBOL-85:
– ALTER
– GOTO without a specified procedure name
– SEGMENTATION
– USE FOR DEBUGGING
Special Methods
Simulated Attribute Methods: Instance variables in COBOL are all private in the
sense that they are fully encapsulated by the class, and are accessible directly only by
the methods that are introduced by the class that defines them. Normally, a well-
designed object-oriented application does not need to access instance variables from
outside the class.
Identification Division.
Method-Id. "somInit" Override.
Procedure Division.
Move Function Current-Date(1:8) To order-date.
Move ð To order-count.
Initialize order-table.
Exit Method.
End Method "somInit".
ENVIRONMENT DIVISION.
CONFIGURATION SECTION.
\ Declare classes used in class defintion
REPOSITORY.
CLASS SOMObject IS 'SOMObject'
CLASS Orders IS 'Orders'.
DATA DIVISION.
\ Define instance data
WORKING-STORAGE SECTION.
ð1 order-number PIC 9(5).
ð1 order-date PIC X(8).
ð1 order-count PIC 99.
ð1 order-table.
ð2 order-entry OCCURS 1ð TIMES.
ð3 order-item PIC X(5).
PROCEDURE DIVISION.
PROCEDURE DIVISION.
MOVE FUNCTION CURRENT-DATE(1:8) TO order-date.
COMPUTE order-number = FUNCTION RANDOM ( 99999 ).
MOVE ð TO order-count.
INITIALIZE order-table.
EXIT METHOD.
END METHOD 'somInit'.
DATA DIVISION.
\ Use LOCAL-STORAGE for items that should be allocated
\ and initialized for each invocation of the method
LOCAL-STORAGE SECTION.
77 sub PIC 99.
ð1 found-flag PIC 9 VALUE 1.
88 found VALUE ð.
LINKAGE SECTION.
ð1 in-item PIC X(5).
ð1 add-flag PIC 9.
DATA DIVISION.
\ Use LOCAL-STORAGE for items that should be allocated
\ and initialized for each invocation of the method
LOCAL-STORAGE SECTION.
77 sub PIC 99.
ð1 found-flag PIC 9 VALUE 1.
88 found VALUE ð.
LINKAGE SECTION.
ð1 out-item PIC X(5).
ð1 delete-flag PIC 9.
DATA DIVISION.
\ Use LOCAL-STORAGE for items that should be allocated
\ and initialized for each invocation of the method
LOCAL-STORAGE SECTION.
77 sub PIC 99.
77 cost PIC 9(5)V99.
LINKAGE SECTION.
ð1 total-cost PIC 9(7)V99.
METHOD-ID. 'getOrderNumber'.
DATA DIVISION.
LINKAGE SECTION.
ð1 ord-num PIC 9(5).
ENVIRONMENT DIVISION.
INPUT-OUTPUT SECTION.
FILE-CONTROL.
SELECT order-file ASSIGN OrdrFile.
DATA DIVISION.
FILE SECTION.
\ Methods support only EXTERNAL files
FD order-file EXTERNAL.
ð1 order-record PIC X(8ð).
\ Use LOCAL-STORAGE for items that should be allocated
\ and initialized for each invocation of the method
LOCAL-STORAGE SECTION.
ð1 print-line.
ð2 print-order-number PIC 9(5).
ð2 print-order-date PIC X(8).
ð2 print-order-count PIC 99.
ð2 print-order-table.
ð3 print-order-entry OCCURS 1ð TIMES.
ð4 print-order-item PIC X(5).
PROCEDURE DIVISION.
OPEN OUTPUT order-file.
MOVE order-number TO print-order-number.
MOVE order-date TO print-order-date.
MOVE order-table TO print-order-table.
MOVE order-count TO print-order-count.
WRITE order-record FROM print-line.
CLOSE order-file.
EXIT METHOD.
END METHOD WriteOrder.
The class and method definitions for the user interface class:
IDENTIFICATION DIVISION.
CLASS-ID. UserInterface INHERITS SOMObject.
ENVIRONMENT DIVISION.
CONFIGURATION SECTION.
\ Declare classes used in class definition
REPOSITORY.
CLASS SOMObject IS 'SOMObject'
CLASS UserInterface IS 'UserInterface'.
DATA DIVISION.
\ Define instance data
WORKING-STORAGE SECTION.
ð1 uif-action PIC X(1ð).
88 uif-add VALUE 'AddItem'.
88 uif-delete VALUE 'DeleteItem'.
88 uif-quit VALUE 'Quit'.
ð1 uif-item PIC X(5).
PROCEDURE DIVISION.
DATA DIVISION.
LINKAGE SECTION.
ð1 action PIC X(1ð).
ð1 item PIC X(5).
Get-Item.
DISPLAY 'Enter the item'.
ACCEPT item FROM SYSIN.
MOVE item TO uif-item.
DATA DIVISION.
LINKAGE SECTION.
ð1 flag PIC 9.
DATA DIVISION.
LOCAL-STORAGE SECTION.
77 formated-cost PIC $Z,ZZZ,ZZ9.99.
LINKAGE SECTION.
ð1 total-cost PIC 9(7)V99.
ð1 order-number PIC 9(5).
DATA DIVISION
PROCEDURE DIVISION
Method Services: A method may request services from another method. Therefore,
a method can be a client and use the statements discussed in this section.
REPOSITORY Paragraph
The REPOSITORY paragraph declares to the compiler that the specified user-defined
word is a class name and optionally relates the class name to an external class name
in the SOM interface repository. You must specify any class name you explicitly refer-
ence in your program in the REPOSITORY paragraph. In the example above, Orders
and UserInterface are the only two classes this program references.
In the above example, three object references are defined. The first two, orderObj and
userObj are typed object references because a class name appears after the OBJECT
REFERENCE phrase. Thus, orderObj can only be used to reference instances of the
Orders class, or one of its subclasses. Likewise, userObj can only be used to refer-
ence instances of the UserInterface class, or one of its subclasses. The other object
reference, univObj, does not have a class name after its OBJECT REFERENCE phrase.
It is a universal object reference and can reference instances of any class.
Remember: Class names used on the OBJECT REFERENCE phrase must be defined in
the REPOSITORY paragraph of the CONFIGURATION SECTION.
When 'somNew' executes it automatically invokes 'somInit', another SOM method, that
you can override to initialize your instance data.
Remember: The class name, in this case Orders, must be defined in the REPOSITORY
paragraph of the CONFIGURATION SECTION. And the object reference, in this case
orderObj, must be defined as USAGE OBJECT REFERENCE in the DATA DIVISION.
When you finish with an instance of a class, you should free it. Again, SOM provides a
method, 'somFree', to free the instance. For example:
Invoke orderObj 'somFree'.
frees the instance of orderObj; orderObj now has an undefined value. When 'somFree'
executes it automatically invokes 'somUninit', another SOM method that you can over-
ride to save or display your instance data.
It may be necessary to make an object reference null or make one object reference
refer to the same instance as another object reference. The SET statement takes care
of these situations:
In the second SET statement, univObj is made to refer to the instance to which
orderObj refers. In this syntax, if the receiver (univObj) is a universal object reference
then the sender (orderObj) can be either a universal or typed object reference.
However, if the receiver is a typed object reference the sender must also be a typed
object reference and typed to the same class or a subclass.
Note: In a method there is a third form of SET object reference:
Set orderObj To Self.
This makes the receiver (orderObj) refer to the same instance on which the
method was invoked, SELF.
Invoking Methods
To receive service from a method, the method must be invoked with the INVOKE state-
ment. For example:
Invoke Orders 'somNew' Returning orderObj.
Invoke orderObj 'AddItem' Using item Returning flag.
In the first INVOKE, a class name is used to create a new instance whose handle is
returned in the object reference orderObj. The class name, Orders, must be defined in
the REPOSITORY paragraph of the CONFIGURATION SECTION. The object reference,
orderObj, must be define as either an universal object reference or a typed to class
Orders object reference.
In the second INVOKE, an object reference, orderObj, is used to invoke the method
AddItem. The general syntax of this form of INVOKE is one of the following:
Invoke objref 'literal-name'.
Invoke objref identifier-name.
In both cases the invoked method must be defined in the class for which the object
reference, objref, is an instance. If the identifier-name form of the method is used, the
object reference, objref, must by an universal object reference.
Conformance between the invoked method and the object reference is checked at
compile time if the following three items are all true:
1. objref is a typed object reference.
2. The literal form of the method name is used in the INVOKE statement.
3. The TYPECHK compile option is specified.
Otherwise, conformance requirements are checked at run time. Run-time checking,
however, is not as thorough as compile-time checking.
INVOKE has the optional scope terminator END-INVOKE. The USING and RETURNING
phrases on the INVOKE work the same as they do on the CALL statement. Also,
INVOKE has the optional ON EXCEPTION and NOT ON EXCEPTION phrases like the CALL
statement. See IBM COBOL Language Reference for a discussion of USING,
RETURNING, ON EXCEPTION, and NOT ON EXCEPTION.
ENVIRONMENT DIVISION.
CONFIGURATION SECTION.
\
\ Declare the classes used in the program
REPOSITORY.
CLASS Orders IS 'Orders'
CLASS UserInterface IS 'UserInterface'.
DATA DIVISION.
WORKING-STORAGE SECTION.
\
\ Declare the object references used in the program
77 orderObj USAGE OBJECT REFERENCE Orders.
77 userObj USAGE OBJECT REFERENCE UserInterface.
\
\ Declare other data items used in the program
77 order-number PIC 9(5).
77 total-cost PIC 9(7)V99.
77 item PIC X(5).
77 action PIC X(1ð).
77 flag PIC 9.
PROCEDURE DIVISION.
\
\ Create an instance of the UserInterface class - userObj
INVOKE UserInterface 'somNew' RETURNING userObj.
\
\ Create an instance of the Orders class - orderObj
INVOKE Orders 'somNew' RETURNING orderObj.
\
\ Read customer input - action and item
INVOKE userObj 'ReadUserInput' USING item action.
\
\ Begin customer driven loop based on action
PERFORM UNTIL action = 'Quit'
\
\ Do appropriate action
\
\ Calculate the total cost of the order
INVOKE orderObj 'ComputeCost' USING total-cost.
\
\ Determine the order number
INVOKE orderObj 'getOrderNumber'
RETURNING order-number.
\
\ Display information about the order
INVOKE userObj 'WriteUserOutput'
USING total-cost order-number.
\
\ Write the order to a file
INVOKE orderObj 'WriteOrder'.
\
\ Free the object instances - orderObj and userObj
INVOKE orderObj 'somFree'.
INVOKE userObj 'somFree'.
STOP RUN.
END PROGRAM 'PhoneOrders'.
In the mail-order catalogue application, Order is a general class. One of the first things
you discover working with Order is there are two kinds of orders: new order and back
order. While both new order and back order have all the characteristics of order, back
order also has the characteristic of requiring the order be read from the file and
checking the status of the items. It might make sense to make new order and back
order subclasses of order, diagramed as follows:
┌───────────┐
│SOMObject │
├───────────┤
│1:somNew │
│2:somInit │
│3:somFree │
│4:somUninit│
│5: ... │
└────┬──────┘
┌─────────┴──────────┐
┌────────┴───────┐ ┌────────┴─────────┐
│Order │ │UserInterface │
│ (order-number) │ │ (action) │
│ (order-date) │ │ (item) │
│ (order-count) │ ├──────────────────┤
│ (order-table) │ │1:ReadUserInput │
├────────────────┤ │2:WriteUserOutput │
│1:AddItem │ │3:WriteUserMessage│
│2:DeleteItem │ └──────────────────┘
│3:CalculateCost │
│4:GetOrderNumber│
│5:WriteOrder │
└────────────┬───┘
┌──────┴─────┐
┌─────┴─────┐ ┌────┴────┐
│BackOrder │ │NewOrder │
├───────────┤ ├─────────┤
│1: │ │1: │
│2: │ │2: │
│3: │ │3: │
│4: │ │4: │
│5: │ │5: │
│6:ReadOrder│ └─────────┘
│7:CheckItem│
└───────────┘
A number and colon with nothing after them represent a method inherited from a super-
class.
In COBOL, a subclass inherits the methods from its superclass. A subclass may
change, or override, one or more methods inherited from its superclass using the OVER-
RIDE clause on the METHOD-ID. Also, a subclass may add new methods it needs to
perform its services.
In COBOL, instance data is private so the superclass must provide methods to allow
the subclass to access instance data. A subclass can retrieve values from or store
values in the instance data using the methods provided by the superclass. A subclass
may also introduce new instance data of its own.
Multiple inheritance, inheriting from more than one superclass, is allowed in COBOL.
Should there be a conflict in method names between two superclasses, the conflict is
resolved according to the System Object Model (SOM) rules. See SOMobjects Devel-
oper's Toolkit User's Guide for an example.
CLASS-ID Paragraph
The CLASS-ID paragraph names the subclass and indicates from what superclass or
superclasses the subclass inherits. In the example above, BackOrder is the class
name. It inherits all the methods from Order. Also, it can access Order instance data if
Order provides methods to get and set its instance data.
REPOSITORY Paragraph
The REPOSITORY paragraph relates your subclass and class names to the subclass
and class names in the SOM interface repository. You must include:
You may optionally include the name of the subclass you are defining. If you do not
include the name of your subclass, it is treated as all upper-case regardless of how you
typed it on the CLASS-ID. In the example above, BackOrder is stored in the SOM inter-
face repository in mixed-case.
WORKING-STORAGE SECTION
A subclass WORKING-STORAGE SECTION describes instance data that is statically allo-
cated when the instance is created and exists until the instance is freed. By default,
the data is global to all the methods introduced by the subclass. Instance data in a
COBOL subclass is private. Thus, it cannot be referenced directly by any other class
or subclass.
METHOD-ID Paragraph
Use the METHOD-ID PARAGRAPH to name the method. Other methods or programs use
this name to invoke the method.
If the subclass defines a method whose name exists in a superclass the OVERRIDE
clause must be specified on the METHOD-ID. For example :
Identification Division.
Method-Id. AddItem Override.
When an object reference that is a handle to the BackOrder subclass invokes AddItem,
this method is invoked rather than the method in the superclass Order.
Note: In a method, a subclass can invoke an overridden superclass method by using
the INVOKE form:
Invoke Super 'AddItem'.
This invokes the method AddItem defined in the superclass rather than the
method AddItem defined in the subclass.
In the case of multiple inheritance, a subclass may inherit several methods with
the same name from different parents. To specify precisely which method from
which parent is invoked use the following INVOKE form:
Invoke Class-A of Super 'AddItem'.
This invokes the method AddItem defined in the superclass Class-A rather than
the method AddItem defined in any other superclass or in the subclass.
If the same data item is used in both the subclass DATA DIVISION and the method DATA
DIVISION, a reference in the method to the data name refers to the data item in the
method DATA DIVISION. The method DATA DIVISION takes precedence.
IDENTIFICATION DIVISION.
CLASS-ID. UserInterface INHERITS SOMObject.
ENVIRONMENT DIVISION.
CONFIGURATION SECTION.
\ Declare classes used in class definition
REPOSITORY.
CLASS SOMObject IS 'SOMObject'
CLASS UserInterface IS 'UserInterface'.
DATA DIVISION.
\ Define instance data
WORKING-STORAGE SECTION.
ð1 uif-action PIC X(1ð).
88 uif-add VALUE 'AddItem'.
88 uif-delete VALUE 'DeleteItem'.
88 uif-quit VALUE 'Quit'.
ð1 uif-item PIC X(5).
PROCEDURE DIVISION.
DATA DIVISION.
LINKAGE SECTION.
ð1 request PIC X(6).
\ Method to read customer input for new request - action and item
IDENTIFICATION DIVISION.
METHOD-ID. ReadUserInput1.
DATA DIVISION.
LINKAGE SECTION.
ð1 action PIC X(1ð).
ð1 item PIC X(5).
Get-Item.
DISPLAY 'Enter the item'.
ACCEPT item FROM SYSIN.
MOVE item TO uif-item.
END METHOD ReadUserInput1.
DATA DIVISION.
LINKAGE SECTION.
ð1 acct-numb PIC 9(5).
DATA DIVISION.
LINKAGE SECTION.
ð1 flag PIC 9.
METHOD-ID. WriteUserOutput.
DATA DIVISION.
LOCAL-STORAGE SECTION.
77 formated-cost PIC $Z,ZZZ,ZZ9.99.
LINKAGE SECTION.
ð1 total-cost PIC 9(7)V99.
ð1 order-number PIC 9(5).
PROCEDURE DIVISION USING total-cost order-number.
MOVE total-cost TO formated-cost.
DISPLAY 'Your order costs ' formated-cost.
DISPLAY 'Your order number is ' order-number.
EXIT METHOD.
END METHOD WriteUserOutput.
DATA DIVISION.
LOCAL-STORAGE SECTION.
77 sub PIC 99.
LINKAGE SECTION.
ð1 out-table.
ð2 out-entry OCCURS 1ð TIMES.
ð3 out-item PIC X(5).
ð1 out-count PIC 99.
The new class and method definitions for the order class:
IDENTIFICATION DIVISION.
CLASS-ID. Orders INHERITS SOMObject.
ENVIRONMENT DIVISION.
CONFIGURATION SECTION.
\ Declare classes used in program
REPOSITORY.
CLASS SOMObject IS 'SOMObject'
CLASS Orders IS 'Orders'.
DATA DIVISION.
\ Define instance data
WORKING-STORAGE SECTION.
ð1 order-number PIC 9(5).
ð1 order-date PIC X(8).
ð1 order-count PIC 99.
ð1 order-table.
ð2 order-entry OCCURS 1ð TIMES.
ð3 order-item PIC X(5).
PROCEDURE DIVISION.
PROCEDURE DIVISION.
MOVE FUNCTION CURRENT-DATE(1:8) TO order-date.
COMPUTE order-number = FUNCTION RANDOM ( 99999 ).
MOVE ð TO order-count.
INITIALIZE order-table.
EXIT METHOD.
END METHOD 'somInit'.
DATA DIVISION.
LINKAGE SECTION.
ð1 in-order.
ð2 in-order-number PIC 9(5).
ð2 in-order-date PIC X(8).
ð2 in-order-count PIC 99.
ð2 in-order-table.
ð3 in-order-entry OCCURS 1ð TIMES.
ð4 in-order-item PIC X(5).
DATA DIVISION.
LINKAGE SECTION.
ð1 out-order.
ð2 out-order-number PIC 9(5).
ð2 out-order-date PIC X(8).
ð2 out-order-count PIC 99.
ð2 out-order-table.
ð3 out-order-entry OCCURS 1ð TIMES.
ð4 out-order-item PIC X(5).
LOCAL-STORAGE SECTION.
77 sub PIC 99.
ð1 found-flag PIC 9 VALUE 1.
88 found VALUE ð.
LINKAGE SECTION.
ð1 in-item PIC X(5).
ð1 add-flag PIC 9.
DATA DIVISION.
LOCAL-STORAGE SECTION.
77 sub PIC 99.
ð1 found-flag PIC 9 VALUE 1.
88 found VALUE ð.
LINKAGE SECTION.
ð1 out-item PIC X(5).
ð1 delete-flag PIC 9.
DATA DIVISION.
LOCAL-STORAGE SECTION.
77 sub PIC 99.
77 cost PIC 9(5)V99.
LINKAGE SECTION.
ð1 total-cost PIC 9(7)V99.
DATA DIVISION.
LINKAGE SECTION.
ð1 ord-num PIC 9(5).
ENVIRONMENT DIVISION.
INPUT-OUTPUT SECTION.
FILE-CONTROL.
SELECT order-file ASSIGN OrdrFile.
DATA DIVISION.
FILE SECTION.
FD order-file EXTERNAL.
ð1 order-record PIC X(8ð).
LOCAL-STORAGE SECTION.
ð1 print-line.
ð2 print-order-number PIC 9(5).
ð2 print-order-date PIC X(8).
ð2 print-order-count PIC 99.
ð2 print-order-table.
ð3 print-order-entry OCCURS 1ð TIMES.
ð4 print-order-item PIC X(5).
PROCEDURE DIVISION.
OPEN OUTPUT order-file.
MOVE order-number TO print-order-number.
MOVE order-date TO print-order-date.
MOVE order-count TO print-order-count.
MOVE order-table TO print-order-table.
WRITE order-record FROM print-line.
CLOSE order-file.
EXIT METHOD.
END METHOD WriteOrder.
The subclass and method definitions for the new order subclass:
IDENTIFICATION DIVISION.
CLASS-ID. NewOrders INHERITS Orders.
ENVIRONMENT DIVISION.
CONFIGURATION SECTION.
\ Declare classes used in subclass defintion
REPOSITORY.
CLASS NewOrders IS 'NewOrders'
CLASS Orders IS 'Orders'.
DATA DIVISION.
PROCEDURE DIVISION.
The subclass and method definitions for the back order subclass:
IDENTIFICATION DIVISION.
CLASS-ID. BackOrders INHERITS Orders.
ENVIRONMENT DIVISION.
CONFIGURATION SECTION.
\ Declare classes used in subclass definition
REPOSITORY.
CLASS BackOrders IS 'BackOrders'
CLASS Orders IS 'Orders'.
DATA DIVISION.
PROCEDURE DIVISION.
ENVIRONMENT DIVISION.
INPUT-OUTPUT SECTION.
FILE-CONTROL.
SELECT backorder-file ASSIGN BackFile.
DATA DIVISION.
FILE SECTION.
FD backorder-file EXTERNAL.
ð1 backorder-record PIC X(8ð).
LOCAL-STORAGE SECTION.
ð1 backorder.
ð2 backorder-number PIC 9(5).
ð2 backorder-date PIC X(8).
ð2 backorder-count PIC 99.
ð2 backorder-table.
ð3 backorder-entry OCCURS 1ð TIMES.
ð4 backorder-item PIC X(5).
77 eof-flag PIC 9 VALUE 1.
88 eof VALUE ð.
LINKAGE SECTION.
ð1 order-number PIC 9(5).
DATA DIVISION.
LOCAL-STORAGE SECTION.
ð1 backorder.
ð2 backorder-number PIC 9(5).
ð2 backorder-date PIC X(8).
ð2 backorder-count PIC 99.
ð2 backorder-table.
ð3 backorder-entry OCCURS 1ð TIMES.
ð4 backorder-item PIC X(5).
77 sub PIC 99.
77 status-flag PIC 9.
88 in-stock VALUE ð.
88 out-stock VALUE 1.
LINKAGE SECTION.
ð1 out-table.
ð2 out-entry OCCURS 1ð TIMES.
ð3 out-item PIC X(5).
ð1 out-count PIC 99.
EXIT METHOD.
END METHOD CheckItem.
ENVIRONMENT DIVISION.
CONFIGURATION SECTION.
\
\ Declare the classes used in the program
REPOSITORY.
CLASS NewOrders IS 'NewOrders'
CLASS BackOrders IS 'BackOrders'
CLASS UserInterface IS 'UserInterface'.
DATA DIVISION.
WORKING-STORAGE SECTION.
\
\ Declare the object references used in the program
\ Note: univObj is a universal object reference
77 univObj USAGE OBJECT REFERENCE.
77 userObj USAGE OBJECT REFERENCE UserInterface.
\
\ Declare other data items used in the program
77 order-number PIC 9(5).
77 total-cost PIC 9(7)V99.
77 out-count PIC 9(2).
77 request PIC X(6).
77 action PIC X(1ð).
77 flag PIC 9.
77 item PIC X(5).
ð1 item-table.
ð2 item-entry OCCURS 1ð TIMES.
ð3 item-element PIC X(5).
PROCEDURE DIVISION.
\
\ Create an instance of the UserInterface class - userObj
INVOKE UserInterface 'somNew' RETURNING userObj.
\
\ Read customer input - request
INVOKE userObj 'ReadUserRequest' USING request.
\
\ What is the customer's request?
IF request = 'STATUS'
PERFORM CheckBackOrder
ELSE
PERFORM CreateNewOrder
END-IF.
\
\ Free the instance of the UserInterface class - userObj
INVOKE userObj 'somFree'.
STOP RUN.
CreateNewOrder.
\
\ Create an instance of the NewOrders class - univObj
INVOKE NewOrders 'somNew' RETURNING univObj.
\
\ Read customer input - action and item
INVOKE userObj 'ReadUserInput1' USING item action.
\
\ Begin customer driven loop based on action
PERFORM UNTIL action = 'Quit'
\
\ Do appropriate action
IF action (1:3) = 'Add'
INVOKE univObj 'AddItem' USING item
RETURNING flag
ELSE
INVOKE univObj 'DeleteItem' USING item
RETURNING flag
END-IF
\
\ Display result of action
INVOKE userObj 'WriteUserMessage' USING OMITTED flag
\
\ Read customer input - action and item
INVOKE userObj 'ReadUserInput1' USING item action
END-PERFORM.
\ End customer driven loop based on action
\
\
\ Calculate the total cost of the order
INVOKE univObj 'ComputeCost' USING total-cost.
\
\ Determine the order number
INVOKE univObj 'getOrderNumber'
RETURNING order-number.
\
\ Display information about the order
INVOKE userObj 'WriteUserOutput'
USING total-cost order-number.
\
\ Write the order to a file
INVOKE univObj 'WriteOrder'.
\
\ Free the NewOrders instance - univObj
INVOKE univObj 'somFree'.
CheckBackOrder.
\
\ Create an instance of the BackOrders class - univObj
INVOKE BackOrders 'somNew' RETURNING univObj.
\
\ Read customer input - order number
INVOKE userObj 'ReadUserInput2' USING order-number.
\
\ Read the back-ordered information from a file
INVOKE univObj 'ReadOrder' USING order-number.
\
\ Check whether the back-ordered items are now in stock
INVOKE univObj 'CheckItem' USING item-table out-count.
\
\ Display the status of the back-ordered items
INVOKE userObj 'WriteUserStatus' USING item-table out-count.
\
\ Free the BackOrders instance - univObj
INVOKE univObj 'somFree'.
Metaclasses have their own methods and can have their own instance data. The most
common use of a metaclass is to control how an instance of a class is created. The
method in the metaclass that creates the instance of a class is a constructor method.
Metaclasses are also useful when multiple instances of a class are created and data
must be gathered from all the instances. See the SOMobjects Developer's Toolkit
User's Guide and SOMobjects Developer's Toolkit Programmer's Reference Manual
(available online) for further details on metaclasses and their uses.
CLASS-ID Paragraph
The CLASS-ID paragraph names the metaclass and indicates from what base System
Object Model (SOM) class the metaclass inherits. In the example above,
MetaBackOrder is the class name. It inherits from the base SOM class SOMClass. All
metaclasses inherit directly or indirectly from SOMClass.
REPOSITORY Paragraph
The REPOSITORY paragraph relates your metaclass and class names to the metaclass
and class names in the SOM interface repository. You must include:
SOM base classes.
In the example above, CLASS SOMClass IS 'SOMClass' indicates what you are
calling SOMClass in your COBOL program is also called SOMClass in the SOM
repository.
User-written classes from which your metaclass is inheriting.
Discussed in “Writing a Subclass Definition” on page 242.
Any class referenced in methods introduced by the metaclass.
You may optionally include the name of the metaclass you are defining. If you do not
include the name of your metaclass, it is treated as all upper-case regardless of how
you typed it on the CLASS-ID. In the example above, MetaBackOrder is stored in the
SOM interface repository in mixed-case.
WORKING-STORAGE SECTION
A metaclass WORKING-STORAGE SECTION describes instance data that is statically allo-
cated when the first instance of an object in the metaclass is created and exists until
the COBOL run-unit terminates. By default, the data is global to all the methods intro-
duced by the metaclass. Instance data in a COBOL metaclass is private. Thus, it
cannot be referenced directly by any other class or metaclass.
If the same data item is used in both the metaclass DATA DIVISION and the method
DATA DIVISION, a reference in the method to the data name refers to the data item in
the method DATA DIVISION. The method DATA DIVISION takes precedence.
Constructor Method
A metaclass constructor method is usually invoked with a class name so the use of the
following INVOKE form is needed in the constructor method to create an instance of the
class:
Invoke Self 'somNew' Returning anObj.
This creates an instance of the class on which the method was invoked, SELF, and
returns the handle to that instance in the object reference anObj.
Method Only: SELF can be used only in a method.
Also, the name of the metaclass must be specified in the REPOSITORY paragraph of the
CONFIGURATION SECTION. For example:
Environment Division.
Configuration Section.
Repository.
Class MetaBackOrder Is 'MetaBackOrder'
Class BackOrder Is 'BackOrder'
Class Order Is 'Order'.
Any method in a metaclass can be invoked with the class name. For example:
Invoke BackOrder 'CountOrders'.
Or, a metaclass object reference can be defined as a handle to the metaclass. For
example:
Working-Storage Section.
ð1 metaObj Usage Object Reference Metaclass BackOrder.
The object reference metaObj is a handle to the metaclass for BackOrder, not a handle
to BackOrder itself.
The first INVOKE statement invokes a SOM method somGetClass which takes an object
reference, backObj, to an instance and returns an object reference, metaObj, for the
metaclass to which backObj belongs.
The second INVOKE statement uses the object reference to the metaclass, metaObj to
invoke the method CountOrders which is defined in the metaclass. See “Complete
Metaclass with Methods Example” for a detailed example of using a metaclass method.
ENVIRONMENT DIVISION.
CONFIGURATION SECTION.
\ Declare classes used in metaclass definition
REPOSITORY.
CLASS MetaBackOrders IS 'MetaBackOrders'
CLASS BackOrders IS 'BackOrders'
CLASS SOMClass IS 'SOMClass'.
DATA DIVISION.
\ Define instance data
WORKING-STORAGE SECTION.
ð1 status-count PIC 99.
PROCEDURE DIVISION.
PROCEDURE DIVISION.
MOVE ð TO status-count.
EXIT METHOD.
END METHOD 'somInit'.
DATA DIVISION.
LINKAGE SECTION.
ð1 order-number PIC 9(5).
ð1 anObj USAGE OBJECT REFERENCE.
DATA DIVISION.
LINKAGE SECTION.
ð1 out-count PIC 9(2).
The new subclass and method definitions for the back order subclass:
IDENTIFICATION DIVISION.
CLASS-ID. BackOrders INHERITS Orders
METACLASS MetaBackOrders.
ENVIRONMENT DIVISION.
CONFIGURATION SECTION.
\ Declare classes used in subclass definition
REPOSITORY.
CLASS MetaBackOrders IS 'MetaBackOrders'
CLASS BackOrders IS 'BackOrders'
CLASS Orders IS 'Orders'.
DATA DIVISION.
PROCEDURE DIVISION.
ENVIRONMENT DIVISION.
INPUT-OUTPUT SECTION.
FILE-CONTROL.
SELECT backorder-file ASSIGN BackFile.
DATA DIVISION.
FILE SECTION.
FD backorder-file EXTERNAL.
ð1 backorder-record PIC X(8ð).
LOCAL-STORAGE SECTION.
ð1 backorder.
ð2 backorder-number PIC 9(5).
ð2 backorder-date PIC X(8).
ð2 backorder-count PIC 99.
ð2 backorder-table.
ð3 backorder-entry OCCURS 1ð TIMES.
ð4 backorder-item PIC X(5).
77 eof-flag PIC 9 VALUE 1.
88 eof VALUE ð.
LINKAGE SECTION.
ð1 order-number PIC 9(5).
DATA DIVISION.
LOCAL-STORAGE SECTION.
ð1 backorder.
ð2 backorder-number PIC 9(5).
ð2 backorder-date PIC X(8).
ð2 backorder-count PIC 99.
ð2 backorder-table.
ð3 backorder-entry OCCURS 1ð TIMES.
ð4 backorder-item PIC X(5).
77 sub PIC 99 VALUE ð.
77 status-flag PIC 9.
88 in-stock VALUE ð.
88 out-stock VALUE 1.
LINKAGE SECTION.
ð1 out-table.
ð2 out-entry OCCURS 1ð TIMES.
ð3 out-item PIC X(5).
ð1 out-count PIC 99.
ENVIRONMENT DIVISION.
CONFIGURATION SECTION.
\
\ Declare the classes used in the program
REPOSITORY.
CLASS NewOrders IS 'NewOrders'
CLASS BackOrders IS 'BackOrders'
CLASS UserInterface IS 'UserInterface'.
DATA DIVISION.
WORKING-STORAGE SECTION.
\
\ Declare the object references used in the program
77 univObj USAGE OBJECT REFERENCE.
\ Note: metaObj is an object reference to a metaclass
77 metaObj USAGE OBJECT REFERENCE METACLASS BackOrders.
77 userObj USAGE OBJECT REFERENCE UserInterface.
\
\ Declare other data items used in the program
77 order-number PIC 9(5).
77 total-cost PIC 9(7)V99.
Chapter 13. Writing Object-Oriented Programs 265
Metaclass Example
PROCEDURE DIVISION.
\
\ Create an instance of the UserInterface class - userObj
INVOKE UserInterface 'somNew' RETURNING userObj.
\
\ Read customer input - request
INVOKE userObj 'ReadUserRequest' USING request.
\
\ What is the customer's request?
IF request = 'STATUS'
PERFORM CheckBackOrder
ELSE
PERFORM CreateNewOrder
END-IF.
\
\ Free the instance of the UserInterface class - userObj
INVOKE userObj 'somFree'.
STOP RUN.
CreateNewOrder.
\
\ Create an instance of the NewOrders class - univObj
INVOKE NewOrders 'somNew' RETURNING univObj.
\
\ Read customer input - action and item
INVOKE userObj 'ReadUserInput1' USING item action.
\
\ Begin customer driven loop based on action
PERFORM UNTIL action = 'Quit'
\
\ Do appropriate action
IF action (1:3) = 'Add'
INVOKE univObj 'AddItem' USING item
RETURNING flag
ELSE
INVOKE univObj 'DeleteItem' USING item
RETURNING flag
END-IF
\
\ Display result of action
\
\ Calculate the total cost of the order
INVOKE univObj 'ComputeCost' USING total-cost.
\
\ Determine the order number
INVOKE univObj 'getOrderNumber'
RETURNING order-number.
\
\ Display information about the order
INVOKE userObj 'WriteUserOutput'
USING total-cost order-number.
\
\ Write the order to a file
INVOKE univObj 'WriteOrder'.
\
\ Free the NewOrders instance - univObj
INVOKE univObj 'somFree'.
CheckBackOrder.
\
\ Read customer input - order number
INVOKE userObj 'ReadUserInput2' USING order-number.
\
\ Begin customer driven loop based order number
PERFORM UNTIL order-number < ð
\
\ Create an instance of the BackOrders class (univObj) and
\ read the back order from a file using a metaclass method
INVOKE BackOrders 'CreateBackOrders'
USING order-number RETURNING univObj
\
\ Check whether the back-ordered items are now in stock
INVOKE univObj 'CheckItem'
USING item-table out-count
\
\ Display the status of the back-ordered items
INVOKE userObj 'WriteUserStatus'
USING item-table out-count
\
\ Read customer input - order number
INVOKE userObj 'ReadUserInput2'
USING order-number
END-PERFORM.
\ End customer driven loop based on order number
\
\
\ Get an object reference to the metaclass
\ Note: 'somGetClass' is a SOM method
INVOKE univObj 'somGetClass' RETURNING metaObj.
\
\ How many back orders were processed?
\ Note: Metaclass object reference to invoke metaclass method
INVOKE metaObj 'CountBackOrders' RETURNING out-count.
\
\ Display number of back orders processed
INVOKE userObj 'WriteUserMessage' USING out-count OMITTED.
\
\ Free the metaclass instance - metaObj
\ Note: This also frees all BackOrders instances
INVOKE metaObj 'somFree'.
Accessing the IR
The interface repository files to be used are specified outside the COBOL program
using a SOM environment variable. The environment variable that specifies the IR is
SOMIR. This environment variable is set as follows:
export SOMIR=/mydir/mycls.ir
If you do not set the SOMIR environment variable, the IR emitter creates a file named
“som.ir” in the current directory.
export SOMIR=/som/som.ir:/dept/dept.ir:/work/work.ir
In this case, som.ir is SOM's IR that is not updated, dept.ir is a stable department IR
that is not updated, and work.ir is the working IR that is updated.
Note: You may need to update the SOMIR environment variable if you delete and
reinstall IBM COBOL Set for AIX, or install another product that updates it.
You may set SOMIR at the time you use it; however, it is easier to put the statement in
the above example into your environment file. For more information see the Interface
Repository chapter of the SOMobjects Developer's Toolkit User's Guide (available
online).
Populating the IR
The IR can be populated with interface information from COBOL classes via the fol-
lowing procedure:
1. Compile the COBOL class definition with the COBOL compiler, specifying the
IDLGEN compiler option.
2. Compile the IDL source files with the SOM compiler, using the IR emitter.
Some COBOL class definitions with complex interdependencies may have to be com-
piled in two steps. For example, there may be circular compilation order dependencies,
such as when two class definitions each contain references to the other. Such complex
configurations may be compiled with the following procedure:
1. Compile all of the COBOL class definition source files with the IDLGEN,
NOTYPECHK, and NOCOMPILE compiler options. This generates IDL files for the
class interfaces, but does not perform type checking or generate an object file.
2. Compile the IDL files with the SOM compiler, using the IR emitter. This populates
the IR with the class interface information.
3. Compile the COBOL class definitions again, with the NOIDLGEN and TYPECHK
compiler options. This final compile performs full type checking and generates
object files.
As with the SOMIR environment variable, you can type these environment variables
when you need them. However, it is easier to put the above “export”" statements in
your environment file. For more information see the SOM Compiler chapter of the
SOMobjects Developer's Toolkit User's Guide (available online).
SOM Initialization
During initialization of programs using object-oriented features, the COBOL run-time
system automatically initializes the SOM environment and creates class-objects for
classes referenced in the application. Application programmers do not have to perform
these initializations manually.
Class Initialization
The SOM architecture specifies that every SOM class exports an initialization function
<classname>NewClass. Normally COBOL programmers do not use this function directly,
but the function is available on all COBOL classes. The COBOL run-time system auto-
matically initializes all classes referenced within a COBOL program by calling their class
initialization functions prior to the execution of the first user-written COBOL statement in
the PROCEDURE DIVISION.
The class initialization function has a case-sensitive name, thus any COBOL program
that explicitly calls a class-initialization function must be compiled with
PGMNAME(LONGMIXED).
For example:
Identification Division.
Class-Id. Employee inherits SOMObject.
Environment Division.
Configuration Section.
Repository.
Class SOMObject is class "SOMObject".
...
End-Class Employee.
and
Identification Division.
Class-Id. Employee inherits SOMObject.
Environment Division.
Configuration Section.
Repository.
Class Employee is class "Employee"
Class SOMObject is class "SOMObject".
...
End-Class Employee.
The SOM engine provides several alternative mechanisms for method resolution (see
SOMobjects Developer's Toolkit User's Guide (available online) for details). IBM
COBOL uses SOM name-lookup resolution to invoke methods. Thus when COBOL
methods are invoked from COBOL code, the somewhat more stringent recompilation
requirements of the SOM offset-resolution mechanism are not applicable. For example,
COBOL methods that are invoked with COBOL INVOKE statements are not subject to
the restriction in item four above. A COBOL method may be relocated anywhere in a
class hierarchy without requiring recompilation of the COBOL programs that invoke the
method.
Methods defined in COBOL classes may be invoked from other languages, such as C
code built with the SOM C emitter, that use offset-resolution. In this case, the standard
SOM requirements apply. Note that COBOL does not provide language comparable to
the SOM “release-order” mechanism, which is used to ensure methods can be added to
a class definition without requiring recompilation of code that invokes the methods using
offset-resolution. When adding methods to an existing COBOL class, it is recom-
mended that the new methods be added at the end of the PROCEDURE DIVISION of the
class definition, after all of the existing methods. This will ensure that any existing code
invoking the original methods does not require recompilation.
The chapter assumes that you understand the System Object Model (SOM), at least
conceptually, and know where to find more detailed documentation about SOM when
you need it. It also assumes that you have access to the documentation for the partic-
ular class library that you are intending to use.
To get started, you need one of the object-enabled IBM COBOL products, together with
the executables for the class library, plus its documentation, as above.
When the library is being used at run time, the components that are present in memory
are illustrated in Figure 62.
Figure 62. Run-time Components of a SOM Class Library. The example also shows the COBOL
components that are using the library.
┌───────────┐ ┌───────────────┐
│ COBOL app ├%─────5┤ Class library │
└─────┬─────┘ └───────┬───────┘
6 6
└───┬───%──────5──┬───┘
6 6
┌──────────┴───────┬─────┴────────────┐
│ SOM Kernel ┌─────┘ C/COBOL run-time │
└──────┬─────┴────────┬──────┬────────┘
6 6 6
┌───────────────┴──────────────┴──────┴──────────────────┐
│ O p e r a t i n g S y s t e m │
└────────────────────────────────────────────────────────┘
8 There are various forms of Interface Definition Language (IDL), such as those for the Distributed Computing Environment (DCE) or
the Object Management Group's Common Object Request Broker Architecture (OMG CORBA), but in this chapter, we shall be
concerned only with IBM's System Object Model Interface Definition Language (SOM IDL). SOM IDL is consistent with CORBA but
also allows some additional data types, such as pointers, that are not included in CORBA.
SOM IDL
The interface information for a SOM class library may be in various forms:
IDL files;
An Interface Repository (IR)—a machine-readable form of IDL, used during compi-
lation;
A book or on-line documentation describing the interfaces in IDL, together with
operational descriptions of the methods.
IDL expresses the contract between the provider of object services, in this case the
class library, and the user of these services: the COBOL program, method or subclass.
The interface description is formally independent of the language in which either the
user of the service or the service itself is implemented. This property is known as
“language-neutrality.” The separation of the interface from the implementation also
allows flexibility in the deployment of the objects on the nodes of a network.
IDL data types have their origins in the C and C++ data model. Because many of them
do not have an exact counterpart in the COBOL language, there needs to be a trans-
lation or “mapping” between IDL and COBOL. The mapping recommended here makes
the explicit assumption that the data structures may be passed directly9 between the
COBOL and C/C++ mappings to SOM IDL.
9 The standard CORBA model presumes a “stub” routine between the invoking and invoked object to do argument translation,
marshalling, and so on. Passing the structures directly yields very significant gains in efficiency, but it also means that some of the
mappings may not seem as “natural” to the COBOL programmer as they would be if the transfer were mediated by a stub routine. It
also means that you must ensure that you have the correct alignment and padding of any structures that are passed across an
interface. In general the recommended way to achieve this for IDL-based interfaces is to specify the SYNCHRONIZED clause for
COBOL mappings to any IDL structs or arrays that directly contain structs
IDL Identifiers
The only IDL names that must be identical in COBOL are the class (IDL interface) and
method (IDL operation) names. These may be specified exactly by using literals:
For a class, in the REPOSITORY paragraph using the CLASS IS clause.
For a method, by using the literal form of the method name in the METHOD-ID para-
graph. When you invoke a method, you use either the literal form of the name or a
data name initialized with the exact method name.
The other identifiers, such as parameter, constant, and exception names, are internal to
your program or class, and don't have to be identical to the IDL. However, it is a good
idea to keep the spelling of these close to that of the IDL originals to enhance the read-
ability and maintainability of your programs.
IDL Operations
IDL operations correspond with COBOL methods, and represent the services that an
IDL interface provides. To use an operation, you code an INVOKE statement with the
appropriate USING and RETURNING phrases that correspond with the parameters and
the return value of the operation. If these parameters are all simple scalar types, the
operation definition is self-contained. But if an operation uses one of the so-called
“constructed” types, you may have to look elsewhere in the documentation for the defi-
nition of the parameter type in order to specify your INVOKE statement completely.
The single input argument is of type color, which is not one of the basic scalar IDL
types. Suppose that color is an IDL enum (see “enum” on page 280) with the following
definition, typically found in a different section of the library documentation:
typedef enum color{red, white, blue};
Then the COBOL code to map the operation, adding the color blue to an object, could
be written as follows:
1 color binary pic 9(9).
88 red value 1.
88 white value 2.
88 blue value 3.
...
Set blue to true
Invoke anobject 'addColor' using by value evp color
The evp argument is the environment pointer, which precedes the explicit operation
arguments. It is used for communicating back to the caller any exceptions that the
operation encounters. See “Errors and Exceptions” on page 297 for a more detailed
discussion.
IDL Attributes
An IDL attribute behaves like instance data that you can see outside the class defi-
nition (but note that there need not be any actual instance variable corresponding with
it). Attributes are modeled as a pair of operations, one to set and one to get the attri-
bute value. Attribute operations return errors by means of standard exceptions.
The mapping for attributes is best explained through an example. Consider the fol-
lowing IDL specification:
interface foo {
struct position_t {
float x, y;
};
float _get_radius();
void _set_radius(in float r);
position_t _get_position();
};
10 Illegal, because IDL identifiers are not permitted to start with an underscore (_) character.
Reference Summary
Figure 63. IDL Type to COBOL Mapping
IDL Type COBOL Equivalent
boolean display picture x [+ level-88s...]
char display picture x
double computational-2
enum binary picture 9(9) [+ level-88s...]
float computational-1
interface object reference
long computational-5 or binary picture s9(9)1
octet display picture x
pointer pointer
short computational-5 or binary picture s9(4)1
string display pic x(n+1), z'value' or variable-length alphanumeric
table2
unsigned long computational-5 or binary picture 9(9)1
unsigned short computational-5 or binary picture 9(4)1
Note:
1. USAGE COMPUTATIONAL-5 data items are available only on the OS/2 and AIX versions of IBM
COBOL. But if you map this IDL type to USAGE BINARY rather than COMP-5, you must either
know that the expected range of values is accommodated by the PICTURE clause, or use the
TRUNC(BIN) compiler option and, on the workstation or PC, ensure that the BINARY(NATIVE)
compiler option is in effect.
Also be aware that there are significant performance effects associated with the use of
COMP-5 data items or the TRUNC(BIN) compiler option (which affects every USAGE BINARY data
item in your program). So if you know that the picture accommodates the expected range of
values, USAGE BINARY may be the better choice.
2. See “string” on page 282 for details.
boolean
The SOM IDL boolean type is mapped to a one-byte alphanumeric data item, together
with suitable level-88 condition names. The condition names are recommended for
convenience, but are not essential. For example, the following IDL:
boolean that;
char
The SOM IDL char type maps to a one-byte alphanumeric data item. The IDL
declaration:
char that;
double
The SOM IDL double type represents 64-bit floating-point data, and is mapped to
USAGE COMPUTATIONAL-2 in IBM COBOL. The IDL definition:
double that;
enum
The closest COBOL equivalent to a SOM IDL enum11 is an unsigned binary full-word,
together with condition name entries for each of the enumeration members. For
example, the following IDL:
enum that{red, white, blue, green};
In the unlikely event that any enumeration member exceeds 999,999,999, decimal
picture considerations may apply—see the note in Figure 63 on page 279.
The way that you refer to a particular enum value in your PROCEDURE DIVISION depends
on whether the value is supplied to an operation, or returned by it. See “Enum Type”
on page 289 for more details.
1. it is always exactly four bytes long, whereas a C/C++ enum is one, two or four bytes long, depending on the maximum enum
value and on compiler options;
2. the members are numbered sequentially starting from one, whereas a C/C++ enum starts at zero by default, or may optionally
have specific values assigned to the enumeration members.
float
The SOM IDL float type represents 32-bit floating-point data and is mapped to
COMPUTATIONAL-1 in IBM COBOL. For IDL:
float that;
interface
The use of an IDL interface as an argument to, or result of, an operation denotes an
object reference to an instance of the class to which the interface has been mapped.
In simple terms, if a method has an interface type as one of its parameters, specify an
OBJECT REFERENCE to an instance of a class that supports that interface. Suppose
you have the following skeletal IDL interface:
interface that {
...
}
You would specify the corresponding class in the REPOSITORY paragraph as usual:
Repository.
class that 'that'.
and pass it according to the rules in “Argument and Return Value Passing Conventions”
on page 287.
long
The SOM IDL long type describes 32-bit signed binary quantities, and is approximated
by USAGE BINARY data items with a PICTURE clause of S9(9) in COBOL. On the work-
station or PC, the type is exactly mapped by a USAGE COMPUTATIONAL-5 data item
with a PICTURE clause of S9(5) through S9(9). Whichever mapping you use, be aware
of the discussion in the note in Figure 63 on page 279.
octet
The SOM IDL octet type represents an 8-bit quantity that is guaranteed to be
unchanged during transmission between different objects. It is most closely matched in
COBOL by a one-byte alphanumeric data item. Thus for IDL:
octet that;
pointer
A SOM IDL pointer corresponds with a COBOL POINTER data item. The IDL
declaration:
pointer that;
short
The SOM IDL short type defines 16-bit signed binary data, and is most closely
matched by COBOL data items with USAGE BINARY and a PICTURE clause of S9(4). On
the workstation or PC, the type is exactly mapped by a USAGE COMPUTATIONAL-5 data
item with a PICTURE clause of S9(1) through S9(4). Whichever mapping you use, be
aware of the discussion in the note in Figure 63 on page 279.
string
The SOM IDL type string is one of the most important types, since it is widely used in
operations and interfaces. It is also one of the most difficult to match in COBOL,
because SOM IDL strings are modeled on those of C and C++. These have a null
terminator to determine the length of the string, and are passed via a typed pointer.
IBM COBOL does not support such null-terminated strings as a native data type.
However, the null-terminated literal — Z'string-value' — alleviates some of the prob-
lems and, when it can be passed BY CONTENT, is an exact match to a SOM IDL in
string.12 A null-terminated literal may also be used to set the initial VALUE of a data
item to be used as a string argument.
In general though, IDL strings are mapped to pointers to the appropriate character
string data or buffer. Except for in strings, what is actually passed in a method invoca-
tion is just the pointer. But, for this to work operationally, the pointer must be set to the
address of the underlying character string data or buffer in PICTURE X format. There
are several styles of data definition, depending on whether the parameter is an in,
inout, or out argument, or a return value. These are discussed in more detail under
“String Type” on page 290. For now, note that the declarations described below may
be used to represent both the COBOL and SOM IDL view of a variable-length string
simultaneously.
The main cases to distinguish are bounded and unbounded strings. Bounded strings
have a fixed upper limit on their size. The IDL declaration:
string<1ðð> that;
represents a SOM IDL string of no more than 100 characters in length, and may be
approximated by the following COBOL data declarations:
1 that-l-max binary pic 9(9) value 1ð1.
1 that-l binary pic 9(9).
1 that.
2 that-v pic x occurs 1 to 1ð1 depending that-l.
The “-l” suffix denotes the length of the string, the “-v” its value. Note the extra posi-
tion to allow for the null terminator, and note that the data item that, in addition to
being a valid SOM IDL string, is also variable-length in COBOL, because of the
OCCURS DEPENDING clause.
For unbounded strings, the maximum length must be inferred from ancillary information
about the interface and the semantics of its operations. Thus, for the IDL declaration:
string that;
which represents an unbounded SOM IDL string, you may, for example, know that the
strings that are passed across the interface do not in practice exceed 4095 characters.
Then the following COBOL declarations would be appropriate:
1 that-l-max binary pic 9(9) value 4ð96.
1 that-l binary pic 9(9).
1 that.
2 that-v pic x occurs 1 to 4ð96 depending that-l.
See “Helper Routines Source Code” on page 308 for the C source code for a pair of
“helper” routines to synchronize the two representations, for example, either the
bounded or unbounded that, above:
'IDLStringToCOBOL' using that that-l
12 See the note in Figure 65 on page 288 about some restrictions on the use of BY CONTENT.
This routine sets the COBOL OCCURS subject that-l from the position of the man-
datory null terminator.
If you prefer, you can achieve the same result in COBOL:
Move that-l-max to that-l
Move zero to tally
Inspect that tallying tally for characters before x'ðð'
Move tally to that-l
'IDLStringFromCOBOL' using that that-l
This routine inserts the null terminator at the string position indicated by the
COBOL OCCURS object.
If you prefer, you can do this quite easily yourself in COBOL:
Move x'ðð' to that-v(that-l)
void
When used as a return type for an operation, the IDL type void means that the opera-
tion doesn't return anything. You map this in COBOL merely by omitting the
RETURNING phrase in the corresponding INVOKE statements or PROCEDURE DIVISION
headers.
Complex Types
These are types that, although defined in SOM IDL, are rarely found as a type definition
or as an argument to or result of an operation.
Reference Summary
Figure 64 (Page 1 of 2). IDL Type to COBOL Mapping
IDL Type COBOL Equivalent
any group + COBOL type
array table
any
The IDL any type is a self-describing representation of any of the IDL types, including
another IDL any. The descriptor is mapped to COBOL as a group item, which includes
a pointer to the actual data item of the particular type. Suppose you want to map the
following IDL declaration:
any that;
The that-value field points to the start of the data for the item that the any represents.
array
IDL arrays map to COBOL tables—groups whose subordinate items contain the
OCCURS clause. The underlying IDL type can be any of the IDL types, including array
itself, and is mapped according to the rules in this or the preceding section.
The “-v” suffix denotes the individual element values. The un-suffixed name is used to
pass the entire array as an argument to a method; the suffixed name is used to refer to
individual elements of the array.
You must specify the SYNCHRONIZED clause on the group item if the array contains a
struct or union at any level of the array. This is to ensure that the subordinate items
are aligned on their natural boundaries, in conformance with the default alignment of
SOM IDL structures.
sequence
An IDL sequence is a one-dimensional array with a descriptor that specifies a maximum
and current size for the sequence. If the maximum size is explicitly declared, the
sequence is said to be “bounded.” Otherwise, the sequence is “unbounded,” and the
maximum size is determined at run time (in an application-specific way) and is set prior
to passing the sequence to an operation. There are no restrictions on the element type
of a sequence. In particular, it is possible to have a sequence of another sequence
type.
The descriptor for the maximum and current size and address of this sequence is
represented in COBOL as a group item:
1 that.
2 that-maximum binary pic 9(9).
2 that-length binary pic 9(9).
2 that-buffer pointer.
Then the element data are mapped as a variable-length table of the appropriate type, in
this case, an array of IDL longs:
1 that-t.
2 that-v binary pic s9(9) occurs 1 to 1ð
depending that-length.
struct
An IDL struct type corresponds with a COBOL group item containing the individually
mapped components of the struct as subordinate data items. Thus the following IDL
struct:
struct that {
long x;
double y;
};
The SYNCHRONIZED clause is required so that the alignment of the subordinate items
approximates the default alignment of SOM IDL structures. In most practical cases, the
alignment would be correct either way, but specifying SYNCHRONIZED is a sensible pre-
caution.
union
A SOM IDL union has a discriminator that indicates which format variant to use. In
COBOL, this is mapped to a group item containing the discriminator, plus the union
itself represented by using the REDEFINES clause. Then, in the PROCEDURE DIVISION,
use an EVALUATE statement to determine which format is currently in effect.
An example should make all this more clear. Suppose you have the following IDL:
union that switch (long) {
case 2:char x;
case 5:long y;
default:float z;
};
The data declaration part of the COBOL mapping could be written as follows:
1 that sync.
2 that-d binary pic s9(9).
2 that-u display pic x(4).
2 that-x redefines that-u display pic x.
2 that-y redefines that-u binary pic s9(9).
2 that-z redefines that-u comp-1.
The SYNCHRONIZED clause makes sure that COBOL mimics the default SOM IDL
alignment rules. Thus, in the unlikely event that any IDL structures have “holes,”
COBOL would insert slack bytes in the record as appropriate.
Notice the extra member of the union, that-u, whose size is the maximum of the sizes
of the explicit union members. This is needed because of the COBOL restriction that a
data item being redefined must be at least as large as the item redefining it. Alterna-
tively, you could just declare the union members in order of decreasing size, although
that may lose the correspondence between the COBOL declaration and the original
IDL.
Whichever style you adopt, you can use an EVALUATE construct such as the following
to determine which of the union members is currently in effect:
Evaluate that-d
When 2
Display 'case 2:IDL-char: ' that-z
When 5
Display 'case 5:IDL-long: ' that-x
When other
Display 'default case:IDL-float: ' that-y
End-evaluate
4. The term “pointer” means a COBOL POINTER that has been set to the address of the equiv-
alent data item or output buffer.
Some kinds of output parameters, IDL strings for example, cannot be expressed
directly in COBOL, but must be mapped to pointers.
Literal Arguments
For return values, and for inout and out arguments, you must pass a data item. For
input arguments however, you may be able to specify a literal, passed BY VALUE:
Integer-valued fixed-point numeric literals and the figurative constant ZERO are
formally equivalent to full-word binary data items, and thus match signed or
unsigned long IDL types.
Floating-point literals are formally equivalent to double-word floating-point
(COMPUTATIONAL-2) data items, and thus match the IDL double type.
Single-byte alphanumeric literals, symbolic characters, and figurative constants
(other than ZERO) match boolean, char, and octet.
or BY CONTENT:
Null-terminated literals of the form Z'value' match the IDL string type.
Note that literal arguments are not supported for enums, because of the risk of the
source getting out of sync with the enumeration list.
Enum Type
The access intent of an enum parameter affects the way you refer to its value, not just
on the INVOKE statement, but also elsewhere in your program. Consider an operation
that expects an enum to be passed in both directions—as an input value and as the
operation result:
that changeColor(in that hue);
typedef enum that{red, white, blue};
To supply a particular color to the operation, you use the corresponding condition name
in a SET statement. For example, to pass the input value white, specify:
1 that-input binary pic 9(9).
88 that-red-input value 1.
88 that-white-input value 2.
88 that-blue-input value 3.
...
Set that-white-input to true
Invoke anObject 'changeColor' using by value evp that-input
returning that-output
Complex Types
For the complex types (not including string, which is discussed separately below), you
pass the level-1 group item. In the examples above, this is always the COBOL data
name that. Where the conventions expect a pointer, this is set:
For an argument, prior to executing the INVOKE statement
For a return value, on return from the method
The rules for passing these types are quite involved and are described in some detail in
the SOMobjects Developer's Toolkit Programming Guide. Generally, you provide the
storage for all in and inout arguments, all modes of struct and union parameters,
and, curiously enough, for out array arguments. The called method allocates some or
all of the storage for all other out arguments and return values. You are not allowed to
modify this returned storage, though you can, of course, use it otherwise, to copy it, for
example. You must free it using OMMFree when you are finished with it. See “Helper
Routines Source Code” on page 308.
If you have to supply inout arguments of any of the complex types, you would do well
to allocate the storage dynamically, using OMMAllocate, and declare the COBOL equiv-
alent type in the LINKAGE SECTION.13 See “Memory Management” on page 304 for
more information about OMMAllocate and OMMFree.
String Type
The examples in this section all presume the SOM IDL declaration:
string<1ðð> that;
You pass in string types in several ways. Where the content is known, you could
specify it as a null-terminated literal, either directly or as the value of a data item:
13 This is because later versions of CORBA allow the called routine to re-allocate inout arguments when the output value is incon-
sistent with the type or size of the input data item. For this to work, a standard memory management protocol must be used by both
the caller and the called routine.
For variable-content strings, you may find it convenient to use a plain (PICTURE X)
alphanumeric data declaration for the string buffer. You can use reference modification
if you want to see the valid part of the string:
1 that-l binary pic 9(9).
1 that pic x(1ð1).
...
Display 'Content of "that" = "' that(1:that-l) '"'
However, if you want the string to behave naturally as a variable-length string in both
COBOL and the SOM IDL-based library, use the dual representations:
1 that-l binary pic 9(9).
1 that.
2 that-v pic x occurs 1 to 1ð1 depending that-l.
You can synchronize either the reference modified or the OCCURS DEPENDING form of
the COBOL string representation with the IDL representation by using the
IDLStringToCOBOL and IDLStringFromCOBOL helper routines given in “Helper Routines
Source Code” on page 308.
For inout and out strings, you must pass the string buffer with an extra level of indi-
rection. The way that you express the extra level of indirection in COBOL is to pass a
pointer, which for inout strings has previously been set to the address of the string
data. As usual, you have a choice of passing this pointer BY REFERENCE, or declaring
a second pointer that you have set to the address of the first, then passing this second
pointer BY VALUE:
1 ptr1 pointer.
1 ptr2 pointer.
1 that-l binary pic 9(9).
...
Linkage section.
1 that.
2 that-v pic x occurs 1 to 1ð1 depending that-l.
...
Set ptr1 to address of that
Invoke anObject 'method' using by value evp by reference ptr1 ...
...
Set ptr2 to address of ptr1
Invoke anObject 'method' using by value evp ptr2
It's clear why the extra level of indirection is needed for out strings, given that they are
allocated by the method and may be arbitrarily long. But the output size of an inout
string is limited by the input size: the upper bound for a bounded string, and the actual
input size for an unbounded string.14
For a return value, specify a pointer, which the method sets to the address of the
output string before it returns.
For all the output modes of string, including inout, declare the string buffer itself in the
LINKAGE SECTION, to allow the method to allocate, or re-allocate, the storage for the
string. Storage for an inout string should be acquired by calling OMMAllocate, so that
(in future) methods can re-size the string if necessary.
Be aware of your responsibilities for any storage allocated and returned by a SOM
IDL-based library method. You can look at the storage, by declaring appropriate
LINKAGE SECTION data items as usual, but do not attempt to modify it.15 If you want to
do that, make a copy of it and modify the copy. Also, note that you are responsible for
freeing the storage for the original returned string when you have finished with it, by
calling the OMMFree routine.
You can find the source code for OMMAllocate and OMMFree under “Helper Routines
Source Code” on page 308.
14 Because of this restriction, inout strings are not very useful, but you still need to pass the pointer rather than the string itself,
because later versions of the CORBA argument conventions do allow reallocation of the string if the output is larger than the input.
15 This is because the storage may be protected, and you cannot assume that you have appropriate write privileges.
Data division.
Local-/Working-storage section.
1 inout-string-p pointer.
1 out-string-p pointer.
1 return-string-p pointer.
...
1 work-string-l binary pic 9(9).
1 inout-string-l binary pic 9(9).
1 out-string-l binary pic 9(9).
1 return-string-l binary pic 9(9).
...
1 work-string pic x(1ðð).
1 in-string pic(1ðð) value z'Nothing strange for in strings'.
1 evp pointer.
...
Linkage section.
1 inout-string.
2 inout-string-v pic x occurs 1 to 1ðð depending inout-string-l.
1 out-string.
2 out-string-v pic x occurs 1 to 1ðð depending out-string-l.
1 return-string.
2 return-string-v pic x occurs 1 to 1ðð depending return-string-l.
1 ev.
2 major binary pic 9(9).
88 no-exception value ð.
...
Procedure division.
...
\ Acquire storage for, and initialize, inout-string:
Move 1ðð to inout-string-l
Call 'OMMAllocate' using content length of inout-string
returning inout-string-p
Set address of inout-string to inout-string-p
Move z'Initial value for inout-string' to inout-string
Call 'IDLStringToCOBOL' using inout-string inout-string-l
\ Invoke method 'that' on an instance of the 'this' class:
Invoke a-this 'that' using by value evp
by reference in-string inout-string-p out-string-p
returning return-string-p
\ De-reference the returned pointers and copy one string:
Set address of inout-string to inout-string-p
Call 'IDLStringToCOBOL' using inout-string inout-string-l
Set address of out-string to out-string-p
Call 'IDLStringToCOBOL' using out-string out-string-l
Set address of return-string to return-string-p
Call 'IDLStringToCOBOL' using return-string return-string-l
Move out-string to work-string
\ Operate on copy, and free allocated storage when done:
Move function reverse(work-string) to work-string
If work-string = out-string then
Display '"' out-string '" is palindromic.'
End-if
...
Call 'OMMFree' using inout-string-p
Call 'OMMFree' using out-string-p
Call 'OMMFree' using return-string-p
...
Operation Example
This section illustrates the COBOL coding to use a very simple class library.
Let us begin by looking at the “documentation” for our class library, which provides a
bucket class. A bucket is a container that lets you add or remove objects, and that can
report the number of objects it contains. Buckets have no special initializer methods,
and can thus be created and initialized correctly just by invoking the somNew method on
the class. Normally, the documentation would define and describe each operation sep-
arately, but for this simple example, we will give the complete interface definition of a
bucket:
interface Bucket {
readonly attribute unsigned long count;
void add(in SOMObject element) raises(BucketFull);
SOMObject remove() raises(BucketEmpty);
};
The raises clause specifies the exceptions that the operation can incur.
The things that we put into our buckets have no external behavior beyond their exist-
ence. That is, they can be created and destroyed, and are identifiable by their object
references, but they have no methods or attributes.
The COBOL program in Figure 66 shows how you might use this class library. It per-
forms the following steps:
1. It creates an instance of a bucket.
2. It creates and adds some things to the bucket.
3. It prints the number of things in the bucket.
4. It removes a thing from the bucket.
5. It again prints the number of things in the bucket.
Procedure division.
display 'Trying Bucket...'
.4/ call 'somGetGlobalEnvironment' returning evp
set address of ev to evp
chkxcp.
if any-exception
display 'An exception occurred; quitting the program!'
stop run
end-if.
Notice that the COBOL coding in this example is very simplistic. For example, it does
not check for errors realistically, or even free all the objects that it creates. But it does
cover most of the things that you have to do to start using a class library. Refer to the
numbered keys in Figure 66 on page 295:
.1/ Regardless of what you call your program, you need to specify the
PGMNAME(LONGMIXED) compiler option to be able to call SOM APIs such as
somGetGlobalEnvironment. The option doesn't affect INVOKE statements, but it
does apply to program names in CALL statements.
.2/, .3/, and .4/ If not stated otherwise, SOM IDL class libraries use callstyle idl.
With this convention, every operation has an implicit environment pointer pre-
ceding the explicit IDL arguments for the operation. Although this argument is
implicit in the IDL, you code it explicitly on your INVOKE statements.
You must, at a minimum, define the environment pointer in the
WORKING-STORAGE or LOCAL-STORAGE SECTION. If you want to examine any
exceptions that are returned, you must also define the exception type in the
LINKAGE SECTION, and set its base address to the value returned by
SOMError is used for internal errors in the kernel classes, and is not really relevant to
the average user. Methods of the kernel classes are used to create an object (somNew
and somNewNoInit) or destroy it (somFree). The main implication of SOMError for these
methods is that you don't have to provide an environment argument when you invoke
them, and of course you don't have to check for exceptions after they return.
However you do need to know how to use the SOM exception mechanism, which is
used for most other methods. Exceptions aren't necessarily errors, but errors do use
the SOM exception mechanism.
SOM exceptions are not the same as C++ exceptions, but instead set the value of an
exception structure, which you can think of as a special kind of “return code,” accessed
via the environment variable.
There are two ways of passing the environment variable, depending on the callstyle of
the method you want to invoke, and check. For each of them, provide a global (per
thread) environment variable, as shown in Figure 67 on page 299. For callstyle oidl
methods, there's no explicit environment variable parameter. Such methods just use
the global environment variable implicitly. Callstyle idl methods, on the other hand,
use the same global environment variable, but passed explicitly, as the first argument to
the method. Again, see Figure 67 on page 299 for an example of how this is accom-
plished in COBOL.
The environment variable is opaque, except for the exception type field (major) at the
beginning of the structure. This is a four-byte C/C++ enum, origin zero, with three
values: NO_EXCEPTION, USER_EXCEPTION and SYSTEM_EXCEPTION — and is coded in
COBOL as BINARY PIC 9(9), with suitable level-88 condition names as illustrated in
Figure 67 on page 299.
Every callstyle idl operation (that is, a method whose first parameter is an environment
structure) can return one of the standard system exceptions16, even if it does not
declare any explicit exceptions with a raises expression in the operation declaration.
This means that you must check the exception type field of the environment variable
after every invocation of a method of a class defined with callstyle idl.
When one of these callstyle idl methods that you've invoked detects a condition that is
to be expressed as an exception, it uses the somSetException function to supply the
exception name and an exception structure.
Then, if you decide to handle the exception, perhaps by printing a message and contin-
uing, you must reset the environment variable and free the associated exception struc-
ture by using the somExceptionFree function. Of course, there are other ways of
handling exceptions. You may want to change the state of one of the input arguments
to the method, then re-try it, or you might prefer to terminate your program rather than
attempting to continue.
But in every case, at a minimum, check the successful completion of each method. It's
not good programming practice to assume that a method completed successfully
without checking it. You will not get a reliable implementation of your application unless
you do so.
COBOL Example
The program fragments in Figure 67 on page 299 show in some detail how you can
accomplish the foregoing in IBM COBOL. The data names are not mandatory; only
suggestions.
16 See the SOMobjects Developer's Toolkit Programming Guide for a list of the CORBA standard exceptions.
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
\ Subroutine to strip leading zeroes \
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
Identification division.
Program-id.
'SLZ'.
Data division.
Linkage section.
1 uint binary pic 9(9).
1 str pic x(9).
1 pos binary pic 9(9).
Procedure division using uint str pos.
Move uint to str
Move ð to pos
Inspect str(1 : length str - 1)
tallying pos for leading 'ð'
Add 1 to pos
Goback
.
End program 'SLZ'.
Initializers
IBM COBOL directly supports the existing somInit and somUninit protocols. For
classes that use somInit, and this includes all pure COBOL classes, you can use the
somNew method to create and initialize an object instance in one step. This is an appro-
priate technique when all instances have the same initial value, or do not have an
explicit initial value at all. If, on the other hand, you want to parameterize object initial-
ization, so that each object instance has a unique initial value, you may prefer the con-
venience of a metaclass; see the discussion of metaclasses later in this section.
You can execute the non-default initializer methods (as a client) of a class by using the
documented technique of first invoking somNewNoInit, then invoking the appropriate
initializer method explicitly. This is the recommended way of creating an instance of
one of the SOM-enabled collections, for example.
You do need to know how to specify the so-called somInitCtrl structure that is used to
control the progress of the initializer as it traverses the class hierarchy. For a client of
a class initializer method (as opposed to a sub-class that provides its own initializer
methods), this structure is initially null, represented in COBOL as an OMITTED argu-
ment. Suppose that the IDL for the initialization method is:
void ISHeap_withNumber(inout somInitCtrl ctrl, in long number);
then COBOL code for invoking this initializer might be:
1 a-heap object reference isheap.
...
Invoke isheap 'somNewNoInit' returning a-heap
Invoke a-heap 'ISHeap_withNumber'
using by value evp by reference omitted by value 1ðððð
For COBOL subclasses of classes that use explicit initializers, the recommended tech-
nique is to use metaclass methods to instantiate and initialize the COBOL object. After
creating the instance, the metaclass method invokes the initializer for each parent (and
with multiple inheritance, there may be several), then initializes any instance data intro-
duced by the subclass itself. There is nothing to prevent you from doing this directly in
the client code; but where it is possible to encapsulate the logic in a metaclass method,
it is both more reliable and more convenient to do so, especially when the subclass
inherits from multiple parents.
Using a metaclass method is also a good way of creating and initializing your own pure
COBOL objects in a single step, particularly where each object may have a unique
initial value.
Sometimes, however, you may need more detailed information about a class library, for
example when you are specializing the library by subclasssing. To get this additional
information, you may need to look at the IDL or header files. It is then helpful to know
their structure: what is relevant and what you can ignore. Consider the sample IDL file
spred from the collection class library, shown in Figure 68 on page 303.
somDefaultInit: override,init;
somDestruct: override;
callstyle = idl;
majorversion = 1;
minorversion = ð;
filestem = spred;
dllname = "sccl.dll";
functionprefix = sISPredicate_;
Typically, the IDL file consists of some IDL definitions, guarded so that they are proc-
essed only once per IDL compilation, plus some implementation-specific information,
also guarded so that it is conditionally included. Refer to the numbered keys in
Figure 68:
.1/ One of three conditional sections in the file; its purpose is to ensure that the IDL
definitions in the file are processed no more than once during the IDL compila-
tion. The matching #endif statement is at the end of the file.
.2/ The #include statement incorporates another IDL file that you may have to refer
to.
.3/ The compound statement specifies the IDL element that this file defines, the
ISPredicate interface.
.4/ This definition is for the (single) new operation evaluateFor that ISPredicate
introduces.
.5/ The start of some SOM-specific implementation information, which needn't
concern you; its matching #endif is the second to last.
.6/ A directive that is needed only by the implementation itself. Again it is not rele-
vant to you, as a client of the class.
Memory Management
It is important to avoid memory leaks. This is particularly true with objects, because
there are typically so many individual object instances created and destroyed. The idea
is to ensure that, when an object is destroyed or assigned, all of its associated storage
is also freed. “Helper Routines Source Code” on page 308 contains the source code
for a pair of C routines that you can use to allocate and free dynamic storage for data
that is pointed to by an object, for an inout argument to a method, and so on:
'OMMAllocate' using storage-size returning a-pointer, to allocate storage,
where storage-size is the 4-byte unsigned binary number of bytes to allocate;
'OMMFree' using a-pointer, to free the previously allocated storage element that
a-pointer addresses.
You must use OMMFree to free output storage allocated and returned to you by SOM
class libraries. See “Complex Types” on page 290 and “String Type” on page 290 for
details of how and when to do this.
You can also use these routines to manage dynamic storage (as opposed to instance
data) for your own classes. Let's look at an example of a variable-length string class,
where the string data is not an explicit part of the instance, but is instead a separate
storage area that the instance refers to.
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
\ COBOL variable-length string class definition. \
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
Identification division.
Class-id.
varstring inherits somobject.
Environment division.
Configuration section.
Repository.
Class varstring 'VarString'
Class somobject 'SOMObject'
.
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
\ Variable-length string class instance data. \
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
Data division.
Working-storage section.
1 vstlen binary pic 9(9).
1 vstptr pointer.
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
\ Variable-length string class method: default initialization; \
\ set the instance to a predictable state. \
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
Identification division.
Method-id.
'somInit' override.
Procedure division.
.1/ Set vstptr to null
Move ð to vstlen
Goback
.
End method 'somInit'.
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
\ Variable-length string class method: assignment from a literal\
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
Identification division.
Method-id.
'SetVarstring'.
Data division.
Local-storage section.
1 strsze pic 9(9) binary.
Linkage section.
1 valptr pointer.
1 setval pic x(1ðð).
1 vstval pic x(1ðð).
Procedure division using by value valptr.
.2/ If vstptr not = null then
Call 'OMMFree' using vstptr
End-if
Move ð to vstlen
Set address of setval to valptr
Inspect setval tallying vstlen
for characters before initial x'ðð'
Add 1 to vstlen giving strsze
Call 'OMMAllocate' using strsze returning vstptr
Set address of vstval to vstptr
Move setval(1:strsze) to vstval(1:strsze)
Goback
.
End method 'SetVarstring'.
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
\ Variable-length string class method: return string (pointer). \
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
Identification division.
Method-id.
'GetVarstring'.
Data division.
Linkage section.
1 valptr pointer.
Procedure division returning valptr.
Set valptr to vstptr
Goback
.
End method 'GetVarstring'.
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
\ Variable-length string class method: assign from another string\
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
Identification division.
Method-id.
'AssignVarstring'.
Data division.
Local-storage section.
1 strsze binary pic 9(9).
1 valptr pointer.
Linkage section.
1 str object reference varstring.
Procedure division using by value str.
.3/ If self not = str then
Invoke str 'GetVarstring' returning valptr
Invoke self 'SetVarstring' using by value valptr
End-if
Goback
.
End method 'AssignVarstring'.
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
\ Variable-length string class method: free associated storage. \
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
Identification division.
Method-id.
'somUninit' override.
Procedure division.
.4/ If vstptr not = null then
Call 'OMMFree' using vstptr
Set vstptr to null
Move ð to vstlen
End-if
Goback
.
End method 'somUninit'.
There are several points to notice about the use of storage in this example:
.1/ All VarString instances are created in a predictable initial state, with the length
set to zero, and the string pointer set to null.
.2/ Before assigning a new value to an instance, the storage allocated for any
current value is freed. If this weren't done, the storage would be “orphaned,”
causing a memory leak.
.3/ When assigning one string to another, you have to check whether the sender is
identical to the receiver before doing the assignment and thereby prematurely
freeing the sender's storage.
/\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\/
/\ Helper functions for using SOM IDL-based class libraries. \/
/\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\/
Batch programs are often constructed to access files and/or databases and produce
reports. In the access files and/or databases case, the file or database is the object of
the action; however, the program is structured around the action—delete, insert, or
update. In the produce reports case, the report can be viewed as an object; however,
the program structure reflects the structure of the report.
Online transaction processing programs are built around the transactions which they
process and these are reflected in the user interface maps or panels which make up
the transaction. Online transactions may access several files or databases from one
panel. In this case, there is a one to many relationship between the source of the
action and the targets of the action, all of which can be viewed as objects.
Subprograms normally are called to provide a function too large or complex to include
in the main program. They are also used to implement general purpose functions
required by many other programs; in which case, they embody reusable code. In many
cases, the subprogram alters the values of some parameters based on the values of
other parameters. In other cases, the subprogram accesses files/databases or prints
reports. In this case, the parameter list can be viewed as a message to trigger some
action on a file or database object.
Glass-top Coordination
This type of wrapper integrates the old and new code at the user interface or
“glass-top” level. As user interfaces move toward a object-oriented approach, you find
direct manipulation used more. This implies actions such as “dragging” and “dropping”
objects into or onto other objects. When this occurs, the objects involved must work
together to take the appropriate action. If one of the objects is really procedure-
oriented code, the wrapper is an interface to the true objects.
For example, you have a stable set of procedural code for updating a database.
However, you would like to include the database as part of a graphical user interface.
The goal is to drop a list object representing an update to the database on the data-
base object and have the update performed. You need to write a wrapper class to
accept messages from the list object; i. e. the list object invokes methods in the
wrapper. The methods in the wrapper class interpret the information from the list object
and use the CALL statement to call the appropriate subprogram in the old procedural
code.
┌────────────────────────────┐User
├────────────────────────────┤Interface
│┌───────┐ drop ┌────────┐│
││List of├────┬────5Database││
││Updates│ │ └────────┘│
│└───────┘ │ │
└─────────────┼──────────────┘
┌──────────┘
┌──6─┐ ┌───────┐ ┌──────────┐ Code
│True│INVOKE│Wrapper│CALL│Procedural│ Level
│O-O %──────5 O-O %────5 Code │
│Code│ │ Code │ └──────────┘
└────┘ └───────┘
You can write a wrapper for each subprogram in the procedural code. Or if several
subprograms are working with the same object, processing the same file or producing
the same report, you can write a single wrapper for all the related subprograms. The
appropriate method in the wrapper is invoked from a true object and the method in turn
calls the appropriate subprogram.
┌──────────┐
│O%──────5O│Object-Oriented
│& &│ Subsystem
││ ││(True Objects)
││ ││-----
│6 6│ |Boundary
│O%──────5O%─5O |Subsystem
└&────────&┘ & |(Wrappers)
|└─5O 6 └─|─────┐
| & O | │
----│-----&------ │
┌───6┐ ┌──6──────┐ ┌──6───┐
│Read│ │Calculate│ │Write │Procedural
│File│ │ Taxes │ │Report│Subsystem
└────┘ └─────────┘ └──────┘
For example:
Identification Division.
Program-Id. ProgB recursive.
Environment Division.
.
.
Coexistence
The object-oriented and procedure-oriented parts of your system can exist quite well
together. Certainly, you want to reuse your existing code as long as it continues to
meet your needs. However, you can add new function to your system using object-
oriented implementations. Only if your existing code no longer meets your needs or its
maintenance cost is too high should you consider converting the entire procedure-
oriented system to an object-oriented system.
Identify Objects
First, partition the DATA DIVISION into potential objects by identifying every record as an
object and every field in the record as its instance data. You can start by taking record
structures that define files and making them objects called FffffFile, where Fffff is a
name of your choosing. Record structures that define database views become objects
called VvvvvView. Map or panel record structures become objects called
UuuuuInterface. Other record structures in the WORKING-STORAGE SECTION not
related to files, databases, maps, or panels become objects called WwwwWork. Finally,
record structures in the LINKAGE SECTION become objects called PppppParameter.
Now you have a lot of potential objects, some of which are redundant. Study the
potential objects and decide if two or more are slight variations of the same object.
Maybe you have two detail lines as potential objects that differ in only one or two of
their fields. If possible use REDEFINES or some other technique to combine the two
detail lines into one and, thus, combine the two potential objects into one object.
The result of this step is an object list with the name of each object and its instance
data.
Trace the data flow between objects to identify those objects which use instance data
from another object.
If the two objects share a superclass - subclass (parent - child) relationship, then the
subclass inherits methods from the superclass and shares instance data via 'get' and
'set' methods. (The get and set methods are written in the superclass definition.)
If the two objects are separate and distinct, then they are collaborators. Collaborators
do not inherit anything from each other. Instance data that needs to be shared
between two collaborators is typically passed as parameters on an INVOKE statement.
The result of this step is an object relationship table listing all the inheritance and col-
laboration relationships between objects.
For example:
Move ð To input-z output-z.
must be changed to
Move ð To input-z.
Move ð To output-z.
The first MOVE is associated with the appropriate input object and the second with the
appropriated output object.
Now couple the procedural instructions from the PROCEDURE DIVISION with the objects
to form methods. Take the code you pulled from the program and organize it into task-
oriented methods.
Refer to the object relationship table from step two and determine if any new methods
must be written to facilitate passing data between two objects. See “Writing a Method
Definition” on page 228 for information about writing methods.
Also, write the client program to create instances of the classes and invoke methods.
See “Writing a Client Definition” on page 237 for information about writing client pro-
grams.
The following information describes some of the differences between development plat-
forms and provides instructions to help you minimize portability problems.
Two compiler options might yield unpredictable results and are flagged by the compiler
with W-level messages:
CMPR2
This compiler option impacts the interpretation of language elements. The AIX
compiler does not support VS COBOL II Release 2 language elements that are in
conflict with the ANSI 85 COBOL standard. A program that depends on the
CMPR2 option is not portable.
NOADV
Programs that require the use of NOADV are sensitive to device control charac-
ters and almost certainly are not portable. If your program relies on NOADV,
revise it such that language specification does not assume a printer control char-
acter as the first character of the ð1 record for the file.
ASSIGN clause
There is a different syntax and mapping to the system filename based on ASSIGN-
MENT name (see the IBM COBOL Language Reference).
CALL statement
A filename as a CALL argument is not supported.
CLOSE statement
The phrases FOR REMOVAL, WITH NO REWIND, and UNIT/REEL are treated as com-
ments. Avoid their use in portable programs.
RERUN clause
Treated as a comment.
WRITE statement
If you specify WRITE...ADVANCING with the environment names C01-C12 or S01-S05,
the ADVANCING phrase is ignored.
For information about the COPY statement, see the IBM COBOL Language Reference.
ASCII vs EBCDIC
The AIX workstation uses the ASCII-based character set while the mainframe uses
the EBCDIC character set. This means that most characters have a different
hexadecimal value. For example, the hexadecimal value for a blank is X'20' in
the ASCII character set and X'40' in the EBCDIC character set.
Code which is dependent on the EBCDIC hexadecimal values of character data
probably fails when run using ASCII. For example, code that tests whether or not
a character is a blank by comparing it with X'40' fails when run using an ASCII
collating sequence.
In the ASCII character set, characters '0' through '9' have the hexadecimal values
X'30' through X'39'. The ASCII lowercase letter 'a' has the hexadecimal value
X'61', and the uppercase letter 'A' has the hexadecimal value X'41'. In the
EBCDIC character set, characters 0 through 9 have the hexadecimal values X'F0'
through X'F9'. In EBCDIC, the lowercase letter 'a' has the hexadecimal value
X'81', and the uppercase letter 'A' has the hexadecimal value X'C1'. These
differences have some important consequences:
While 'a' < 'A' is true for EBCDIC, it is false for ASCII.
While 'A' < '1' is true for EBCDIC, it is false for ASCII.
While x >= '0' almost always means that x is a digit in EBCDIC, this is not
true for ASCII.
Because of these differences, the results of sorting character strings are different
under EBCDIC and ASCII. For many programs, this has no effect, but you should
be aware of potential logic errors if your program depends on the exact sequence
in which some character strings are sorted. If your program is dependent on the
EBCDIC collating sequence and you are porting it to AIX, you can obtain the
EBCDIC collating sequence using PROGRAM COLLATING SEQUENCE IS EBCDIC or
the COLLSEQ(EBCDIC) compiler option.
To avoid problems with the different data representation between ASCII and
EBCDIC characters, use the CHAR(EBCDIC) compiler option. For more information,
see “CHAR” on page 151.
IEEE vs HEXADEC
The AIX workstation represents floating-point data using the IEEE format while the
mainframe uses the hexadecimal format.
Figure 71 summarizes the differences between normalized floating-point IEEE and
hexadecimal for USAGE COMP-1 data:
Figure 71. Normalized IEEE vs. Normalized Hexadecimal for COMP-1 Data
Specification IEEE Hexadecimal
Range ±1.17E-38 to ±5.4E-79 to
±3.37E+38 ±7.2E+75
Exponent representation 8 bits 7 bits
Mantissa representation 23 bits 24 bits
Accuracy 6 digits 6 digits
Figure 72. Normalized IEEE vs. Normalized Hexadecimal for COMP-2 Data
Specification IEEE Hexadecimal
Range ±2.23E-308 to ±5.4E-79 to
±1.67E+308 ±7.2E+75
Exponent representation 11 bits 7 bits
Mantissa representation 52 bits 56 bits
Digits of accuracy 15 digits 16 digits
For most programs these differences should create no problems. However, use
caution in porting if your program depends on hexadecimal representation of data.
To avoid most problems with the different representation between IEEE and
hexadecimal floating-point data, use the FLOAT(S390) compiler option. For more
information, see “FLOAT” on page 165.
File names
File naming conventions on the AIX workstation are very different from those on
the mainframe. The following file name, for example, is valid on the AIX work-
station but not on the mainframe:
/users/joesmith/programs/cobol/myfile.cbl
This can have an effect on portability if you use file names in your COBOL source
programs.
Case Sensitivity: Unlike the mainframe, AIX is case-sensitive. Names used in
source programs (such as upper-case file names) should be named appropriately
in AIX file directories.
Control codes
Some characters that have no particular meaning on the mainframe are interpreted
as control characters by AIX. This can lead to incorrect processing of ASCII text
files. Files should not contain any of the following characters:
If your program is written to respond to status key data items, you should be concerned
with two issues, depending on whether the program is written to respond to the first
status key or the second status key:
1. If your program is written to respond to the first file status data item (data-name-1),
be aware that values returned in the 9X range are platform-dependent. If your
program depends on the interpretation of a particular 9X value (for example, 97),
do not expect the value to have the same meaning on the workstation that it does
on the mainframe. Instead, revise your program so that it responds to any 9X
value as a generic I/O failure.
2. If your program is written to respond to the second file status data item
(data-name-8), be aware that the values returned are both platform and file system
dependent. For example, VSAM returns values with a different record structure on
the mainframe than it does on the workstation. If your program relies on the inter-
pretation of the second file status data item, it is probably not portable.
For more information about the FILE STATUS clause, see the IBM COBOL Language
Reference.
Specifically, consider how you refer to files in the following language elements:
ACCEPT or DISPLAY target names
ASSIGN clause
COPY statement (text-name and library-name)
When a run unit consists of several, separately compiled programs that call each other,
the programs must be able to communicate with each other. They need to transfer
control and usually need to have access to common data. The following sections
describe the methods that allow separately compiled programs to communicate with
one another.
COBOL programs that are nested within each other can also communicate. All the
required subprograms for an application can be contained in one program and thereby
require only a single compilation. This method is explained in “Structure of Nested
Programs” on page 324.
The called COBOL program starts running at the top of the PROCEDURE DIVISION.
Not Recomended: You can specify another entry point where the program will begin
running by using the ENTRY label in the called program. However, this is not recom-
mended in a structured program.
Recursive Calls
If a called program directly or indirectly executes its caller (such as program X calling
program Y; program Y calling program Z; and program Z then calling program X), this is
called a recursive call. Recursive calls are allowed if you code the RECURSIVE attribute
on the PROGRAM-ID paragraph of the recursively invoked program and/or if you specify
the THREAD compiler option. If you try to recursively call a COBOL program that does
not have the RECURSIVE attribute coded on its PROGRAM-ID paragraph, the run unit will
end abnormally.
For considerations in using the LINKAGE SECTION with recursive calls, see “With
Recursion or Multithreading” on page 22.
COBOL program is the main program. Otherwise, it and all other COBOL programs in
the run unit are subprograms.
Calls to nested programs allow you to create applications using structured programming
techniques. They can also be used in place of PERFORM procedures to prevent unin-
tentional modification of data items. Calls to nested programs can be made using
either the CALL literal or CALL identifier statement. For more information on nested
programs, see “Structure of Nested Programs.”
Figure 73 describes a nested program structure with directly and indirectly nested pro-
grams.
┌──────────Id Division.
X is the outermost program │ Program─Id. X.
and directly contains X1 and ─────────5│ Procedure Division.
X2, and indirectly contains │ Display "I'm in X"
X11 and X12 │ Call "X1"
│ Call "X2"
│ Stop Run.
│ ┌──────Id Division.
X1 is directly contained │ │ Program─Id. X1.
in X and directly ─────────│─5│ Procedure Division.
contains X11 and X12 │ │ Display "I'm in X1"
│ │ Call "X11"
│ │ Call "X12"
│ │ Exit Program.
│ │ ┌───Id Division.
X11 is directly │ │ │ Program─Id. X11.
contained in X1 ────────│──│─5│ Procedure Division.
and indirectly │ │ │ Display "I'm in X11"
contained in X │ │ │ Exit Program.
│ │ └───End Program X11.
│ │ ┌───Id Division.
X12 is directly │ │ │ Program─Id. X12.
contained in X1 ────────│──│─5│ Procedure Division.
and indirectly │ │ │ Display "I'm in X12"
contained in X │ │ │ Exit Program.
│ │ └───End Program X12.
│ └──────End Program X1.
│ ┌──────Id Division.
│ │ Program─Id. X2.
X2 is directly ───────────────────│─5│ Procedure Division.
contained in X │ │ Display "I'm in X2"
│ │ Exit Program.
│ └──────End Program X2.
└─────────End Program X.
Figure 73. Nested Program Structure with Directly and Indirectly Contained Programs
rectly) in the same program as the common program. Only nested programs can be
identified as COMMON. Recursive calls are not allowed.
Figure 74 shows the outline of a nested structure with some nested programs identified
as COMMON.
┌───Program─Id. A.
│
│ ┌───Program─Id. A1.
│ │
│ │ ┌───Program─Id. A11.
│ │ │
│ │ │ ┌───Program─Id. A111.
│ │ │ │
│ │ │ └───End Program A111.
│ │ └───End Program A11.
│ │ ┌───Program─Id. A12 is Common.
│ │ │
│ │ └───End Program A12.
│ └───End Program A1.
│ ┌───Program─Id. A2 is Common.
│ │
│ └───End Program A2.
│ ┌───Program─Id. A3 is Common.
│ │
│ └───End Program A3.
└───End Program A.
The following table describes the calling hierarchy for the structure that is shown in
Figure 74. Programs A12, A2, and A3 are identified as COMMON, and t he calls associ-
ated with them differ.
Figure 75. Calling Hierarchy for Nested Structures with COMMON programs
This Program Can call these programs And can be called by these pro-
grams
A A1, A2, A3 None
A1 A11, A12, A2, A3 A
A11 A111, A12, A2, A3 A1
A111 A12, A2, A3 A11
A12 A2, A3 A1, A11, A111
A2 A3 A, A1, A11, A111, A12, A3
A3 A2 A, A1, A11, A111, A12, A2
Note that:
A2 cannot call A1 because A1 is not common and is not contained in A2.
A1 can call A2 because A2 is common.
Scope of Names
Names in nested programs are divided into two classes: local and global. The class
determines whether a name is known beyond the scope of the program that declares it.
A specific search sequence locates the declaration of a name after it is referenced in a
program.
Local Names: Names are local unless declared to be otherwise (except the program
name). Local names are not visible or accessible to any program outside of the one in
which they were declared; this includes both contained and containing programs.
Global Names: A name that is global (indicated using the GLOBAL clause) is visible
and accessible to the program in which it is declared, and to all the programs that are
directly and indirectly contained in that program. This allows the contained programs to
share common data and files from the containing program, simply by referencing the
name of the item.
Any item that is subordinate to a global item (including condition names and indexes) is
automatically global.
The same name can be declared with the GLOBAL clause more than one time, pro-
viding that each declaration occurs in a different program. Be aware that masking, or
hiding, a name in a nested program is possible by having the same name occur in
different programs of the same containing structure. This could possibly cause some
problems when a search for a name declaration is taking place.
Note that the search is for a global name, not for a particular type of object associated
with the name, such as a data item or file connector. The search stops when any
match is found, regardless of the type of object. If the object declared is of a different
type than that expected, an error condition exists.
time, it is provided in a library and is loaded either when the caller is loaded or when it
is called.
Static linking and dynamic linking are done for COBOL CALL literal subprograms only.
See “Static Linking Overview” on page 386 for a discussion on static linking. See
“Shared Library Overview” on page 386 for a discussion of dynamic linking.
Run-time resolution is always done for COBOL CALL identifier and is done for CALL
literal when the DYNAM option is in effect.
CALL identifier
The COBOL CALL identifier, where identifier is a data item that contains the name of a
non-nested subprogram when the program is run, always results in the target subpro-
gram being loaded when it is called. Also, the name of the DLL must match the name
of the target entry point. See “Terminology Notes” on page 387 for a discussion of
COBOL terminology.
CALL literal
The COBOL CALL literal, where literal is the explicit name of a non-nested subprogram
being called, can be resolved statically, dynamically or at run time. If the NODYNAM
compile-time option is in effect, either static or dynamic linking can be done. If DYNAM
is in effect, the CALL literal is resolved the same as CALL identifier: the target subpro-
gram is loaded when it is called, and the name of the DLL must match the name of the
target entry point.
These call definitions apply only in the case of a COBOL program calling a non-nested
program. When a COBOL program calls a nested program, the CALL is resolved by
the compiler without any system intervention.
For a detailed description of the CALL statement, see the IBM COBOL Language Refer-
ence. For more information on calling subprograms in shared libraries see Chapter 23,
“Building Shared Libraries” on page 386.
– Collapsing some active stack frames from one language with active stack
frames written in another language in the to-be-collapsed stack frames (C
longjmp()).
– Terminating run unit/process from one language while stack frames written in
another language are active: For example, COBOL STOP RUN and C exit() or
_exit().
Instead, the application should be structured in such a way that an invoked
program terminates by returning to its invoker.
These function can be used in an ILC environment as long as the use of such a
function does not result in collapsing of active stack frame(s) of a language other
than the one initiating such a function.
This is a guideline and will not be enforced. Potential adverse effects for the lan-
guages not initiating the collapsing/termination are:
– Normal clean-up/exit functions of the language might not be performed.
An example is the closing of files by COBOL on a run unit termination, or the
clean-up of dynamically acquired resources by the involuntarily terminated lan-
guage.
– User specified exits/functions for the exit/termination might not be invoked.
Examples are destructors and the C atexit() function.
Exception Handling
Exceptions incurred during the execution of a stack frame written in one language
might not be processed according to the rules of other languages active in the
invocation stack.
In general, such an exception will be handled according to the rules of the lan-
guage incurring the exception.
This COBOL product will save the exception environment on entry to the COBOL
run time environment and restores it on termination of the COBOL environment.
COBOL expects interfacing languages and tools to follow the same convention.
Since the COBOL implementation does not depend on the interception of
exceptions through system services for the support of ANSI COBOL language
semantics, the user can specify the run-time option, TRAP(OFF), to enable the
exception handling semantics of the non-COBOL language.
The following table shows the correspondence between the data types available in
COBOL and C/C++.
long int PIC 9(5)-9(9) COMP-5. Can be COMP, COMP-4, or BINARY if you use the
TRUNC(BIN) compiler option.
long long int PIC 9(10)-9(18) COMP-5. Can be COMP, COMP-4, or BINARY if you use
the TRUNC(BIN) compiler option.
float COMP-1
double COMP-2
enumeration Equivalent to level 88, but not identical.
char(n) PICTURE X(n)
array pointer (*) to type No appropriate COBOL equivalent.
pointer(*) to function PROCEDURE-POINTER
You must declare a function return value on the CALL statement that calls a C/C++
function.
You must map COBOL data types to appropriate C/C++ data types.
These concepts are illustrated in the following COBOL source program, cobcallc.cbl:
\
\ The following CALL returns the C function return value.
\
CALL "MyFunR" USING BY VALUE N4 RETURNING NS9
DISPLAY "n4=" N4 " and ns9= n4 times n4= " NS9
MOVE -35792568ð.25 TO D1
CALL "MyFunD" USING BY VALUE D1 RETURNING D2
DISPLAY "d1=" D1 " and d2= 2.ð times d2= " D2
MOVE 11111 TO NR1
MOVE 22222 TO NR2
MOVE 33333 TO NR3
CALL "MyFunV" USING R1
STOP RUN.
For a detailed description of the CALL statement, see the IBM COBOL Language Refer-
ence.
#include <stdio.h>
void
MyFun(short \ps1, short s2, long \k1, long \k2, double \m)
{
double x;
x = 2.ð\(\m);
printf("MyFun got s1=%d s2=%d k1=%d k2=%d x=%f\n",
\ps1, s2, \k1, \k2, x);
}
long
MyFunR(short s1)
{
return(s1 \ s1);
}
double
MyFunD(double d1)
{
double z;
void
MyFunV(long \pn)
{
printf("MyFunV got %d %d %d\n", \pn, \(pn+1), \(pn+2));
}
Figure 78. MyFun.C - A C Program That Calls and is Called by COBOL Programs
The file tprog1.cbl is called by the C function MyFunD in the C program MyFun.c (see
Figure 78 on page 333). The called COBOL program contains the following source
code:
\
IDENTIFICATION DIVISION.
PROGRAM-ID. TPROG1.
\
DATA DIVISION.
LINKAGE SECTION.
\
ð1 X USAGE COMP-2.
\
PROCEDURE DIVISION USING X.
DISPLAY "TPROG1 got x= " X
GOBACK.
For additional information, see Chapter 26, “Pre-initializing the COBOL Run-Time
Environment” on page 415.
Figure 80. Result Compiling and Running the Examples in This Chapter
This chapter will describe how to write programs that can share data with other pro-
grams. For the purposes of this discussion, a “subprogram” is any program called by
another program.
Passing Data
Data can be passed between programs in three ways:
BY REFERENCE The subprogram refers to and processes the data items in
storage of the calling program rather than working on a copy of
the data.
BY CONTENT The calling program passes only the contents of the literal, or
identifier. With a CALL . . . BY CONTENT, the called program
cannot change the value of the literal or identifier in the calling
program, even if it modifies the variable in which it received the
literal or identifier.
BY VALUE The calling program or method is passing the value of the literal,
or identifier, not a reference to the sending data item.
Here, storage for these items is allocated in the highest outermost program. That is,
program A calls program B, which calls program C. Data items in program A can be
described in the LINKAGE sections of programs B and C, and the one set of data can
be made available to all three programs.
If you reference data in a file, the file must be open when the data is referenced.
Code the USING clause of the CALL statement to pass the arguments.
Code the USING clause after the PROCEDURE-DIVISION header to receive the parame-
ters.
LINKAGE SECTION
The number of data-names in the identifier list of a called program must not be greater
than the number of data-names in the identifier list of the calling program. There is a
one-to-one positional correspondence; that is, the first identifier of the calling program is
passed to the first identifier of the called program, and so forth. The compiler does not
try to match arguments and parameters.
PROCEDURE DIVISION
If an argument was passed BY VALUE, the PROCEDURE DIVISION header of the subpro-
gram must indicate that:
PROCEDURE DIVISION USING BY VALUE.
If an argument was passed BY REFERENCE or BY CONTENT, the PROCEDURE DIVISION
header does not need to indicate how the argument was passed.
To make the possibility of mismatched records even smaller, put the level-01 record in
a COPY library, and copy it in both programs. (That is, copy it in the
WORKING-STORAGE SECTION of the calling program and in the LINKAGE SECTION of the
called program.)
Null-Terminated Strings
Null-terminated strings are supported using syntax shown in the IBM COBOL Language
Reference. You can manipulate null-terminated strings passed from a C program, for
example, by using string handling mechanisms such as those found below:
ð1 L pic X(2ð) value z'ab'.
ð1 M pic X(2ð) value z'cd'.
ð1 N pic X(2ð).
ð1 N-Length pic 99 value zero.
ð1 Y pic X(13) value 'Hello, World!'.
For this example, picture a chained list of data that is composed of individual salary
records. Figure 82 shows one way to visualize how these records are linked in
storage:
┌─────────┐ ┌──────────┐
│ │ │ │
SALARY RECORD 6 │ 6 │ 6
┌───────────┴─┐ ┌──────────┴─┐ ┌─────────────┐
PTR─NEXT─REC │addr of next │ │ │ │NULL invalid │
│rec │ │ │ │addr │
NAME ├─────────────┤ ├────────────┤ . . . ├─────────────┤
│ │ │ │ │ │
SALARY ├─────────────┤ ├────────────┤ ├─────────────┤
│ │ │ │ │ │
└─────────────┘ └────────────┘ └─────────────┘
The first item in each record points to the next record, except for the last record. The
first item in the last record contains a null value instead of an address, to indicate that it
is the last record.
The high-level logic of an application that processes these records might look some-
thing like this:
OBTAIN ADDRESS OF FIRST RECORD IN CHAINED LIST FROM ROUTINE
CHECK FOR END OF THE CHAINED LIST
DO UNTIL END OF THE CHAINED LIST
PROCESS RECORD
GO ON TO THE NEXT RECORD
END
Figure 83 on page 341 contains an outline of the processing program, LISTS, used in
this example of processing a chained list.
IDENTIFICATION DIVISION.
PROGRAM-ID. LISTS.
ENVIRONMENT DIVISION.
DATA DIVISION.
\\\\\\
WORKING-STORAGE SECTION.
77 PTR-FIRST POINTER VALUE IS NULL.
77 DEPT-TOTAL PIC 9(4) VALUE IS ð.
\\\\\\
LINKAGE SECTION.
ð1 SALARY-REC.
ð2 PTR-NEXT-REC POINTER.
ð2 NAME PIC X(2ð).
ð2 DEPT PIC 9(4).
ð2 SALARY PIC 9(6).
ð1 DEPT-X PIC 9(4).
\\\\\\
PROCEDURE DIVISION USING DEPT-X.
\\\\\\
\ FOR EVERYONE IN THE DEPARTMENT RECEIVED AS DEPT-X,
\ GO THROUGH ALL THE RECORDS IN THE CHAINED LIST BASED ON THE
\ ADDRESS OBTAINED FROM THE PROGRAM CHAIN-ANCH
\ AND CUMULATE THE SALARIES.
\ IN EACH RECORD, PTR-NEXT-REC IS A POINTER TO THE NEXT RECORD
\ IN THE LIST; IN THE LAST RECORD, PTR-NEXT-REC IS NULL.
\ DISPLAY THE TOTAL.
\\\\\\
CALL "CHAIN-ANCH" USING PTR-FIRST
SET ADDRESS OF SALARY-REC TO PTR-FIRST
\\\\\\
PERFORM WITH TEST BEFORE UNTIL ADDRESS OF SALARY-REC = NULL
IF DEPT = DEPT-X
THEN ADD SALARY TO DEPT-TOTAL
ELSE CONTINUE
END-IF
SET ADDRESS OF SALARY-REC TO PTR-NEXT-REC
END-PERFORM
\\\\\\
DISPLAY DEPT-TOTAL
GOBACK.
On return from the call to CHAIN-ANCH, PTR-FIRST contains the address of the first
record in the chained list.
PTR-FIRST is initially defined as having a null value as a logic check. If something goes
amiss with the call, and PTR-FIRST never receives the value of the address of the first
record in the chain, a null value remains in PTR-FIRST and, according to the logic of the
program, the records will not be processed.
NULL is a figurative constant used to assign the value of an invalid address (non-
numeric 0) to pointer items. It can be used in the VALUE IS NULL clause, in the SET
statement, and as one of the operands of a relation condition with a pointer data item.
The LINKAGE SECTION of the calling program contains the description of the records in
the chained list. It also contains the description of the department code that is passed,
using the USING clause of the CALL statement.
LINKAGE SECTION.
ð1 SALARY-REC.
ð2 PTR-NEXT-REC POINTER.
ð2 NAME PIC X(2ð).
ð2 DEPT PIC 9(4).
ð2 SALARY PIC 9(6).
ð1 DEPT-X PIC 9(4).
A pointer data item can be assigned the value NULL in two ways:
A pointer data item can be defined with a VALUE IS NULL clause in its data defi-
nition.
NULL can be the sending field in a SET statement.
In the case of a chained list in which the pointer data item in the last record contains a
null value, the code to check for the end of the list would be:
IF PTR-NEXT-REC = NULL
.
.
.(logic for end of chain)
If you haven't reached the end of the list, process the record and move on to the next
record.
In the program LISTS, this check for the end of the chained list is accomplished with a
DO WHILE structure:
PERFORM WITH TEST BEFORE UNTIL ADDRESS OF SALARY-REC = NULL
IF DEPT = DEPT-X
THEN ADD SALARY TO DEPT-TOTAL
ELSE CONTINUE
END-IF
SET ADDRESS OF SALARY-REC TO PTR-NEXT-REC
END-PERFORM
Then repeat the record-processing routine, which will process the next record in the
chained list.
Because pointer data items are not numeric, you cannot directly perform arithmetic on
them. However, you can use the SET verb to increment the passed address in order to
bypass header information.
Within the Procedure Division, “base” the address of SALARY-REC on the address of
REAL-SALARY-REC:
SET ADDRESS OF SALARY-REC TO ADDRESS OF REAL-SALARY-REC
Therefore, if you set your procedure-pointer item to an entry address in a load module
called using CALL-identifier and your program subsequently CANCELs that called
module, then your procedure-pointer item becomes undefined, and reference to it there-
after is not reliable.
For a complete definition of the USAGE IS PROCEDURE-POINTER clause and the SET
statement, refer to the IBM COBOL Language Reference.
You can also use the RETURNING phrase on the PROCEDURE DIVISION header in your
method to return information to an invoking program or method. If you use PROCE-
DURE DIVISION. . .RETURNING with CALL. . .RETURNING, the RETURN-CODE register will
not be set.
Setting of the RETURN-CODE by the called program is limited to calls between COBOL
programs. For example, if your COBOL program calls a C program, you can't expect
the calling program's RETURN-CODE to be set.
For equivalent functionality between COBOL and C programs, have your COBOL
program call the C program with the RETURNING option. If the C program (function)
correctly declares a function value, the RETURNING value of the calling COBOL
program will be set.
INVOKE Note: The RETURN-CODE special register is not set by use of the INVOKE
statement.
Upon successful return from the called program to its caller, the value in data-name-2 is
stored into the identifier specified in the CALL-RETURNING phrase:
CALL . . . RETURNING dataname2
CALL . . . RETURNING
The RETURNING phrase on the CALL statement can be specified for calls to functions
written in C/C++ or subroutines written in COBOL.
dataname2 must be defined in the DATA DIVISION of the calling COBOL program. The
data type of the return value declared in the target function must be identical to the
data type of dataname2.
Any COBOL program or method in the run unit, having the same data description for
the item as the program containing the item, can access and process the data item.
For example, if program A had the following data description:
ð1 EXT-ITEM1 EXTERNAL PIC 99.
program B could access that data item by having the identical data description in its
WORKING-STORAGE SECTION.
Remember, any program that has access to an EXTERNAL data item can change its
value. Do not use this clause for data items you need to protect.
The rules for using EXTERNAL files are described in the IBM COBOL Language Refer-
ence. In addition, it is recommended that:
The data-name in the FILE STATUS clause of all the programs that will check the
file status code must match.
For all programs that want to check the same file status field, the EXTERNAL clause
should be coded on the level-01 data definition for the file status field in each
program.
Each subprogram can control a single I/O function, such as OPEN or READ.
Each program has access to the file.
Each program in the example declares a data item with the EXTERNAL clause in its
WORKING-STORAGE SECTION. This item is used for checking file status codes, and is
also placed using the COPY statement.
Identification Division.
Program-Id.
ef1.
\
\ This is the main program that controls the external file
\ processing.
\
Environment Division.
Input-Output Section.
File-Control.
Copy efselect.
Data Division.
File Section.
Copy effile.
Working-Storage Section.
Copy efwrkstg.
Procedure Division.
Call "ef1openo"
Call "ef1write"
Call "ef1close"
Call "ef1openi"
Call "ef1read"
If ef-record-1 = "First record" Then
Display "First record correct"
Else
Display "First record incorrect"
Display "Expected: " "First record"
Display "Found : " ef-record-1
End-If
Call "ef1close"
Goback.
End Program ef1.
Identification Division.
Program-Id.
ef1openo.
\
\ This program opens the external file for output.
\
Environment Division.
Input-Output Section.
File-Control.
Copy efselect.
Data Division.
File Section.
Copy effile.
Working-Storage Section.
Copy efwrkstg.
Procedure Division.
Open Output ef1
If efs1 Not = ð
Display "file status " efs1 " on open output"
Stop Run
End-If
Goback.
End Program ef1openo.
Identification Division.
Program-Id.
ef1write.
\
\ This program writes a record to the external file.
\
Environment Division.
Input-Output Section.
File-Control.
Copy efselect.
Data Division.
File Section.
Copy effile.
Working-Storage Section.
Copy efwrkstg.
Procedure Division.
Move "First record" to ef-record-1
Write ef-record-1
If efs1 Not = ð
Display "file status " efs1 " on write"
Stop Run
End-If
Goback.
End Program ef1write.
Identification Division.
Program-Id.
ef1openi.
\
\ This program opens the external file for input.
\
Environment Division.
Input-Output Section.
File-Control.
Copy efselect.
Data Division.
File Section.
Copy effile.
Working-Storage Section.
Copy efwrkstg.
Procedure Division.
Open Input ef1
If efs1 Not = ð
Display "file status " efs1 " on open input"
Stop Run
End-If
Goback.
End Program ef1openi.
Identification Division.
Program-Id.
ef1read.
\
\ This program reads a record from the external file.
\
Environment Division.
Input-Output Section.
File-Control.
Copy efselect.
Data Division.
File Section.
Copy effile.
Working-Storage Section.
Copy efwrkstg.
Procedure Division.
Read ef1
If efs1 Not = ð
Display "file status " efs1 " on read"
Stop Run
End-If
Goback.
End Program ef1read.
Identification Division.
Program-Id.
ef1close.
\
\ This program closes the external file.
\
Environment Division.
Input-Output Section.
File-Control.
Copy efselect.
Data Division.
File Section.
Copy effile.
Working-Storage Section.
Copy efwrkstg.
Procedure Division.
Close ef1
If efs1 Not = ð
Display "file status " efs1 " on close"
Stop Run
End-If
Goback.
End Program ef1close.
Figure 86 on page 352 shows how to read the command line arguments:
..
.
IDENTIFICATION DIVISION.
PROGRAM-ID. "targaix".
\
ENVIRONMENT DIVISION.
CONFIGURATION SECTION.
\
DATA DIVISION.
WORKING-STORAGE SECTION.
\
linkage section.
ð1 PARM-LEN PIC S9(9) COMP.
ð1 OS-PARM.
ð2 PARMPTR-TABLE OCCURS 1 TO 1ðð TIMES DEPENDING ON PARM-LEN.
ð3 PARMPTR POINTER.
ð1 PARM-STRING PIC XX.
\
PROCEDURE DIVISION USING BY VALUE PARM-LEN BY REFERENCE OS-PARM.
display "parm-len=" parm-len
SET ADDRESS OF PARM-STRING TO PARMPTR(2).
DISPLAY "parm-string= '" PARM-STRING "'";
EVALUATE PARM-STRING
when "ð1" display "case one"
when "ð2" display "case two"
when "95" display "case ninety five"
when other display "case unknown"
end-evaluate
GOBACK.
..
.
IDENTIFICATION DIVISION.
PROGRAM-ID. "testarg".
\
ENVIRONMENT DIVISION.
CONFIGURATION SECTION.
\
DATA DIVISION.
WORKING-STORAGE SECTION.
\
linkage section.
ð1 os-parm.
ð5 parm-len pic s999 comp.
ð5 parm-string.
1ð parm-char pic x occurs ð to 1ðð times
depending on parm-len.
\
PROCEDURE DIVISION using os-parm.
display "parm-len=" parm-len
display "parm-string='" parm-string "'"
evaluate parm-string
when "ð1" display "case one"
when "ð2" display "case two"
when "95" display "case ninety five"
when other display "case unknown"
end-evaluate
GOBACK.
These basics of coding SQL in a COBOL program are described in detail in the DB2
Application Programming Guide and the DB2 SQL Reference.
Because the compiler is working in conjunction with the DB2 co-processor, DB2 must
be started before you compile your program. To be connected to the target database
for the compile, you can connect before you start the compile or have the compiler
make the connection for you by specifying the database either using the DATABASE
suboption in the SQL option or by naming it in the DB2DBDFT environment variable.
The SQL options that you include in the suboption string are cumulative. See the DB2
Command Reference for information on these options.
Note that the concatenated strings are delimited with single spaces. When multiple
instances of the same SQL suboptions are found, the last specification of that sub-
option in the concatenated string will be in effect.
This concatenation of multiple SQL option specifications allows you to separate SQL
suboptions which may not fit into a single CBL statement into multiple CBL statements.
The compiler limits the length of the concatenated DB2 option string to 4K bytes.
Package Name
The base name (the source file name or the PROGRAM ID) is modified as follows:
Names longer than eight characters are truncated to eight characters
Letters are folded to upper case
Any character other than A-Z, 0-9, or _ (under score) is changed to 0
If the first character is not alphabetic, it is changed to A
Thus, if the base name is 9123aB-cd, the package name would be A123AB0C.
Unless explicitly specified, the file name is relative to the current directory.
Ignored Options
The following options, which were meaningful to and used by the pre-processor, are
ignored by the co-processor:
MESSAGES
NOLINEMACRO
OPTLEVEL
OUTPUT
SQLCA
TARGET
WCHARTYPE
For example,
EXEC SQL INCLUDE name
is treated identically to
COPY name.
The name on an SQL INCLUDE statement follows the same rules as those for the copy
text-name and is processed identically to a COPY statement with that text-name without
a REPLACING clause. See “Compiler Environment Variables” on page 129 and the dis-
cussion on the COPY statement in the “Compiler-Directing Statements” on page 187
section for details.
COBOL does not use the DB2 environment variable DB2INCLUDE for SQL INCLUDE
processing.
If you have been using DB2INCLUDE for your SQL INCLUDE processing, you can simply
concatenate it with the setting of the COBOL SYSLIB environment variable in the
.profile file in your home directory or at the prompt presented in an AIX command
shell. For example, export SYSLIB=$DB2INCLUDE:$SYSLIB
It is recommended that binary data items that are specified in an SQL statement be:
Declared as USAGE COMP-5 or
Used with the TRUNC(BIN) option if USAGE BINARY, COMP or COMP-4 item is speci-
fied
If you specify a BINARY, COMP, or COMP-4 item with option TRUNC(OPT) or TRUNC(STD)
in effect, it will be accepted by the compiler but may invalidate the data due to the
application of the decimal truncation rule. It is your responsibility to insure that trun-
cation does not affect the validity of the data.
For information about using SQL with System/390 host data types, see Appendix B,
“System/390 Host Data Type Considerations” on page 469.
The following list outlines the 8 general steps involved in preparing a COBOL applica-
tion that runs under CICS:
1. Initialize the CICS environment. Note that the environment variables for CICS are
set when the CICS region is started. The system administrator sets the values in
the file /var/cics_regions/xxx/environment (where xxx is the name of the region)
and then starts the region. Your system administrator should set the environment
variables necessary for you to access programs, mapsets, copybooks, and files.
2. Create your COBOL application. For CICS-specific COBOL programming consid-
erations, see “Preparing COBOL Applications to Run under CICS” on page 359.
Specifically, use an editor to do the following:
Code your program using COBOL statements and CICS commands
Create COBOL copybooks
Create CICS screen maps used by your program
For a detailed description of COBOL programming under CICS, see the CICS
Application Programming Guide.
3. Process the CICS screen maps using the cicsmap command.
4. Use the CICS command CICSTCL to:
Compile The COBOL compiler will be invoked and the program will be com-
piled.
7. Select the CICS region where your resources are defined. Depending on how your
system is configured, you may have to first sign into CICS using the supplied trans-
action CESN.
8. Run the application by entering its 4-character CICS transaction-id.
In addition to the COBOL words restricted by the IBM-supplied default reserved word
table, the IBM-supplied CICS reserved word table restricts the following COBOL words:
It is recommended that you do not use the FILE SECTION of the DATA DIVISION.
Do not use user-specified parameters to the main program.
It is recommended that you do not use USE declaratives (except USE FOR DEBUG-
GING).
The following COBOL language statements are not recommended for use in a
CICS environment:
| – ACCEPT (Format 1 or 2— see “System Date under CICS” on page 361)
– CLOSE
– DELETE
– DISPLAY
– MERGE
– OPEN
– READ
– REWRITE
– SORT
– START
– STOP literal
– WRITE
| Attention: Apart from some forms of the ACCEPT statement, mainframe CICS
does not support any of the COBOL language elements in the preceding
list. If you use any of these COBOL language elements, be aware that:
– The application is not completely portable to the mainframe CICS envi-
ronment.
– In the case of a CICS failure, a backout (restoring the resources asso-
ciated with the failed task) will not be possible.
When coding nested (contained) programs, pass DFHEIBLK and DFHCOMMAREA as
parameters to any nested programs that contain EXEC commands and/or refer-
ences to the EIB. The same parameters must also be passed to any program that
forms part of the control hierarchy between such a program and its top level
program.
COMP-5 can be used instead of BINARY, COMP, or COMP-4 as EXEC CICS command
arguments. COMP-5 is treated with the behavior of BINARY, COMP, or COMP-4 as if
BINARY(NATIVE) and TRUNC(BIN) were in effect, regardless of explicitly setting those
options.
WORD(CICS) is recommended if you want those COBOL language elements not sup-
ported under CICS to be flagged at compile time.
The PGMNAME(MIXED) option must be used for applications that use CICS Client.
The following options should be avoided when compiling programs to run in a CICS
environment:
DYNAM
NOLIB
TRUNC(STD) or TRUNC(OPT)
All other COBOL compiler options are supported. For detailed information on individual
compiler options, see Chapter 10, “Compiler Options” on page 147.
For additional information about CICS access and System/390 host data types, see
Appendix B, “System/390 Host Data Type Considerations” on page 469.
Some data access methods (such as VSAM) can carry out such conversions automat-
ically, but you should not assume that the data will be converted. If your program is
designed to access mainframe data, you might want to add logic to your program to
test whether or not the data is EBCDIC and, if necessary, carry out an explicit collating
sequence conversion.
Notice that since alpha is a COBOL program containing CICS statements, CICS control
blocks DFHEIBLK and DFHCOMMAREA must be passed to alpha. The source for alpha
is in the file ALPHA.ccp. The CICS command cicstcl is used to translate, compile, and
link ALPHA.ccp, and it produces ALPHA.ibmcob. Notice that COBOL defaults to upper
case names (you can change this by using the PGMNAME(MIXED) option), so it is impor-
tant to name the source ALPHA.ccp (not alpha.ccp) in order to produce ALPHA.ibmcob
and not alpha.ibmcob.
Suppose the CICS region is called green, then ALPHA.ibmcob needs to be copied to
/var/cics_regions/green/bin and the AIX SMIT tool has to be used to define ALPHA
as a CICS program.
| DLL Considerations
| The same DLL containing COBOL program(s) should not be used in more than one run
| unit within the same CICS transaction, or the results will be unpredictable. For
| example, Figure 88 shows a CICS transaction where the same subprogram is called
| from two different run units.
| ┌────────────────┐
| │ Program A │
| │ │
| │ │
| │ │
| │ CALL ──────────┼─────────────────────────────┐
| │ │ │
| │ │ │
| │ │ ┌────────────────┐ │
| │ EXEC CICS LINK ├──────5│ Program B │ │
| │ │ │ │ │
| └────────────────┘ │ │ │ ┌─────────────────┐
| │ │ │ │ C.DLL │
| │ │ │ ├──────────────┐ │
| │ │ └──────5│ Program C │ │
| │ CALL ──────────┼───────────5│ │ │
| │ │ │ │ │
| │ │ │ │ │
| │ │ ├──────────────┘ │
| └────────────────┘ │ │
| │ │
| │ │
| In this example:
| Program A CALLs Program C (in C.DLL)
| Program A LINKs to Program B using an EXEC CICS LINK command. This
| becomes a new run unit within the same transaction.
| Program B CALLs Program C (in C.DLL)
| Programs A and B are sharing the same copy of Program C, and any changes to its
| state will affect both. In the CICS environment, programs in a DLL are initialized (both
| the WSCLEAR compiler option and VALUE clause initialization) only on the first call
| within a run unit. If a COBOL subprogram is called more than once, from either the
| same or different main programs, the subprogram will be initialized only on the first call.
| If you need the subprogram initialized on the first call from each main program, you
| should statically link a separate copy of the subprogram with each calling program.
| If you need the subprogram initialized on every call, you should use one of the following
| methods:
| Put data to be reinitialized in the subprogram's Local-Storage Section, rather than
| Working-Storage. Note that this affects initialization by the VALUE clause only, not
| by the WSCLEAR compiler option.
| CANCEL the subprogram after each use, so the next call will be to the program in
| its initial state.
| Add the INITIAL attribute to the subprogram.
Therefore, if your COBOL program invokes a C/C++ program that contains CICS com-
mands (or vice versa), use EXEC CICS LINK or EXEC CICS XCTL rather than the COBOL
CALL statement.
If an invoked COBOL method calls another COBOL program that is processed by the
CICS translator (because it contains CICS commands), the CALL statement must pass
the addresses of DFHEIBLK and DFHCOMMAREA as the first two parameters. This
requires the invoker of the COBOL method to pass the addresses of DFHEIBLK and
DFHCOMMAREA as the first two parameters on the INVOKE statement. It further
requires the PROCEDURE DIVISION statement of the COBOL method to include
DFHEIBLK and DFHCOMMAREA as the first two parameters in its USING list.
In summary, let COBPGM1 and COBPGM2 denote two COBOL programs and let
COBCLASS denote an object-oriented COBOL class with METHOD1 and METHOD2 as its
methods. To prepare and run an application program that consists of COBPGM1,
COBPGM2, and COBCLASS under CICS AIX, consider the following:
COBPGM1 and COBPGM2 can contain EXEC CICS commands. If they do, they
should be translated before compilation.
COBCLASS methods METHOD1 and METHOD2 cannot contain EXEC CICS com-
mands.
COBPGM1 and COBPGM2 can access methods METHOD1 and METHOD2 using the
INVOKE statement.
COBPGM1 and COBPGM2 cannot access methods METHOD1 and METHOD2 using
the CALL statement.
COBPGM1 and COBPGM2 cannot use the EXEC CICS LINK or the EXEC CICS XCTL
command to access methods METHOD1 and METHOD2.
DFHEIBLK and DFHCOMMAREA should be passed to methods METHOD1 and
METHOD2 if they call a COBOL program that contains CICS commands.
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
\ Program Client - File a.ccp \
\ \
\ A simple COBOL program which issues CICS commands and invokes \
\ COBOL method sayHello. Since sayHello will call another COBOL \
\ program (Client2), Client passes DFHEIBLK and DFHCOMMAREA on \
\ the INVOKE statement to sayHello. \
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
Identification Division.
Program-id. Client.
Environment Division.
Configuration Section.
Repository.
Class Hello.
Data Division.
Working-Storage Section.
ð1 H usage object reference Hello.
77 Msg1 Pic X(3ð) Value "About to invoke a method".
77 Msg2 Pic X(3ð) Value "Returned from invoked method".
Procedure Division.
Invoke Hello "somNew" returning H
EXEC CICS SEND FROM(Msg1) LENGTH(3ð) ERASE END-EXEC.
Invoke H "sayHello" Using DFHEIBLK DFHCOMMAREA
EXEC CICS SEND FROM(Msg2) LENGTH(3ð) ERASE END-EXEC.
Invoke H "somFree"
EXEC CICS RETURN END-EXEC.
GOBACK.
End Program Client.
Identification Division.
Method-id. sayHello.
Data Division.
Linkage Section.
ð1 DFHEIBLK Pic X.
ð1 DFHCOMMAREA Pic X.
Procedure Division Using DFHEIBLK DFHCOMMAREA.
Display "Hello, World!".
Call "Client2" Using DFHEIBLK DFHCOMMAREA.
End Method sayHello.
Identification Division.
Method-id. sayMsg.
Procedure Division.
Display Msg.
End Method sayMsg.
Identification Division.
Method-id. "_Set_Msg".
Data Division.
Linkage Section.
ð1 In-Msg Pic X(2ð).
Procedure Division Using In-Msg.
Move In-Msg to Msg.
End Method "_Set_Msg".
Identification Division.
Method-id. "_Get_Msg".
Data Division.
Linkage Section.
ð1 Out-Msg Pic X(2ð).
Procedure Division Returning Out-Msg.
Move Msg to Out-Msg.
End Method "_Get_Msg".
Use the cicsterm command to select the CICS region and access a CICS terminal.
Enter the 4-character transaction-id at the CICS terminal.
You may want to create a shell script that accepts several arguments, such as each
element of an application program, and performs the above steps in one invocation.
Alternatively, you can debug CICS programs using the graphical debugger shipped with
the product. See the CICS documentation for instructions about how to invoke the
graphical debugger under CICS. Be sure to instruct the compiler to produce symbolic
information used by the graphical debugger (see “Compiling and Linking Programs” on
page 135).
Your COBOL applications that use embedded SQL for database access must be proc-
essed by a preprocessor or coprocessor for a particular database and have to be
recompiled if the target database changes. Because ODBC is a call interface, there is
no compile-time designation of the target database as there is with embedded SQL.
Not only can you avoid having multiple versions of your application for multiple data-
bases, but your application can dynamically determine which database to target.
Introducing ODBC
ODBC is a specification for an application program interface (API) that enables applica-
tions to access multiple database management systems using Structured Query Lan-
guage (SQL).
ODBC permits maximum interoperability: a single application can access many dif-
ferent database management systems. This enables you to develop, compile, and ship
an application without targeting a specific type of data source. Users can then add the
database drivers, which link the application to the database management systems of
their choice.
Background
The X/Open Company and the SQL Access Group jointly developed a specification for
a callable SQL interface, referred to as the X/Open Call Level Interface. The goal of
this interface is to increase portability of applications by enabling them to become inde-
pendent of any one database vendor's programming interface.
ODBC was originally developed by Microsoft for Microsoft operating systems based on
a preliminary draft of X/Open CLI. Since this time, other vendors have provided ODBC
drivers that run on other platforms, such as OS/2 and UNIX systems.
| The descriptions and examples in this chapter apply to ODBC Version 3.0. However,
| Version 2.x support is also provided. If you are developing your application for Version
| 2.x ODBC, you will need to use the Version 2.x copybooks instead of the Version 3.0
| copybooks listed here. For details, see “Using the Supplied Copybooks” on page 371.
For details on the ODBC APIs, see the on-line help for the ODBC product that you
have installed.
For specific information related to an ODBC driver, such as the ODBC level or exten-
sions supported by that driver, please refer to the specifications available with that
driver.
| The supplied copybook, odbc3.cpy, defines the symbols for constant values described
for ODBC APIs, mapping constants used in calls to ODBC APIs to symbols specified in
ODBC guides so that argument (input and output) and function return values can be
specified and tested.
A COPY statement to include this copybook should be specified in the DATA DIVISION as
follows:
For a program, the COPY statement should be specified in the WORKING-STORAGE
SECTION, in the outer-most program if programs are nested.
Note that the last approach can be used only if the target argument, SomeArgument, is a
level 01 item in the LINKAGE SECTION. If SomeArgument is a level 01 item in the
LINKAGE SECTION, the addressibility to SomeArgument can be set in one of the following
ways:
1. Explicitly via
SET ADDRESS OF SomeArgument TO a-pointer-data-item
or
SET ADDRESS OF SomeArgument to ADDRESS OF an-identifier
or
2. Implicitly by having SomeArgument passed in as an argument to the program from
which the ODBC function call is being made.
| ...
| WORKING-STORAGE SECTION.
| COPY ODBC3.
| ...
| ð1 SQL-RC COMP-5 PIC S9(4).
| ð1 Henv POINTER.
| ...
| PROCEDURE DIVISION.
| ...
| CALL "SQLAllocHandle"
| USING
| By VALUE sql-handle-env
| sql-null-handle
| By REFERENCE Henv
| RETURNING SQL-RC
| IF SQL-RC NOT = (SQL-SUCCESS or SQL-SUCCESS-WITH-INFO)
| THEN
| DISPLAY "SQLAllocHandle failed."
| ...
| ELSE
| ...
The above is further illustrated using SQLConnect function. Any one of the following
| examples can be used for calling the SQLConnect function:
| Example 1:
| ...
| CALL "SQLConnect" USING BY VALUE ConnectionHandle
| BY REFERENCE ServerName
| BY VALUE SQL-NTS
| BY REFERENCE UserIdentifier
| BY VALUE SQL-NTS
| BY REFERENCE AuthentificationString
| BY VALUE SQL-NTS
| RETURNING SQL-RC
| ...
| Example 2:
| ...
| SET Ptr-to-ServerName TO ADDRESS OF ServerName
| SET Ptr-to-UserIdentifier TO ADDRESS OF UserIdentifier
| SET Ptr-to-AuthentificationString TO ADDRESS OF AuthentificationString
| CALL "SQLConnect" USING BY VALUE ConnectionHandle
| Ptr-to-ServerName
| SQL-NTS
| Ptr-to-UserIdentifier
| SQL-NTS
| Ptr-to-AuthentificationString
| SQL-NTS
| RETURNING SQL-RC
| ...
| Example 3:
| ...
| CALL "SQLConnect" USING BY VALUE ConnectionHandle
| ADDRESS OF ServerName
| SQL-NTS
| ADDRESS OF UserIdentifier
| SQL-NTS
| ADDRESS OF AuthentificationString
| SQL-NTS
| RETURNING SQL-RC
| ...
Note that the BY REFERENCE or BY VALUE phrase applies to all arguments until over-
ridden by another BY REFERENCE, BY VALUE, or BY CONTENT phrase.
identifier-1
This is the field being tested. It must be a 2-or 4-byte binary number field, that is,
USAGE COMP-5 PIC 9(4) or PIC 9(9).
identifier-2
This is the bit mask field to select the bits to be tested. It must be defined with the
same USAGE and PICTURE as identifier-1.
identifier-3
This is the return value for the test and has the following return values:
Multiple bits can be set in a field using COBOL arithmetic expressions with the bit
masks defined in the ODBCCOB copybook. For example, the bits for SQL-CVT-CHAR,
SQL-CVT-NUMERIC, and SQL-CVT-DECIMAL can be set in the InfoValue field by:
COMPUTE InfoValue = SQL-CVT-CHAR + SQL-CVT-NUMERIC + SQL-CVT-DECIMAL
After setting InfoValue, it can be passed to the iwzTestBits function as the second
argument.
Note that the operands of the arithmetic expression above represent disjoint bits from
each other as defined for each of such bit mask symbols in ODBCCOB copybook. You
should be careful not to repeat the same bit in an arithmetic expression for this purpose
(since the operations are arithmetic additions not logical ORs). For example,
COMPUTE InfoValue = SQL-CVT-CHAR + SQL-CVT-NUMERIC + SQL-CVT-DECIMAL
+ SQL-CVT-CHAR
will result in InfoValue not having the SQL-CVT-CHAR bit on.
| In addition to the odbc3.cpy copybook, the two other copybooks are odbc3d.cpy and
| odbc3p.cpy. Also a skeleton sample program, odbc3eg.cbl, illustrating the use of these
copybooks is included.
| odbc3p.cpy includes COBOL procedure statements that can be performed for initializa-
tion, termination, and error processing.
Example Notes:
1. The PGMNAME(MIXED) compiler option should be used; the ODBC entry points are
case sensitive.
2. System/390 host data type options should not be used; ODBC APIs expect their
parameters to be in native format.
| 3. The sample code (odbc3eg.cbl, odbc3p.cpy, and odbc3d.cpy) is located in the
| samples/odbc subdirectory under the main COBOL install directory.
| 4. odbc3.cpy is in the include subdirectory under the main COBOL install directory.
5. Including these two subdirectories in your SYSLIB environment variable will ensure
that the copybooks are available to the compiler.
| cbl pgmname(mixed)
| \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
| \ ODBC3EG.CBL \
| \----------------------------------------------------------------\
| \ Sample program using ODBC3, ODBC3D and ODBC3P COPY books \
| \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
| IDENTIFICATION DIVISION.
| PROGRAM-ID. "ODBC3EG".
| DATA DIVISION.
| WORKING-STORAGE SECTION.
| \ copy ODBC API constant definitions
| COPY "odbc3.cpy" SUPPRESS.
| PROCEDURE DIVISION.
| Do-ODBC SECTION.
| Start-ODBC.
| DISPLAY "Sample ODBC 3.ð program starts"
| \ allocate hstmt
| PERFORM Allocate-Statement-Handle
| \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
| \ add application specific logic here \
| \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
| \ clean-up environment
| PERFORM ODBC-Clean-Up.
| \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
| \ ODBC3D.CPY (ODBC Ver 3.ð) \
| \----------------------------------------------------------------\
| \ Data definitions to be used with sample ODBC function calls \
| \ and included in WORKING-STORAGE or LOCAL-STORAGE SECTION \
| \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
| \ ODBC Handles
| ð1 Henv POINTER VALUE NULL.
| ð1 Hdbc POINTER VALUE NULL.
| ð1 Hstmt POINTER VALUE NULL.
| \\\\\\\\\\\\\\\\\\\\\\\\\
| \ End of ODBC3D.CPY \
| \\\\\\\\\\\\\\\\\\\\\\\\\
| \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
| \ ODBC3P.CPY \
| \----------------------------------------------------------------\
| \ Sample ODBC initialization, clean-up and error handling \
| \ procedures (ODBC Ver 3.ð) \
| \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
| \\\ Initialization functions SECTION \\\\\\\\\\\\\\\\\\\\\\\\\\\\\
| ODBC-Initialization SECTION.
| \
| Allocate-Environment-Handle.
| CALL "SQLAllocHandle" USING
| BY VALUE SQL-HANDLE-ENV
| BY VALUE SQL-NULL-HANDLE
| BY REFERENCE Henv
| RETURNING SQL-RC
| SQLDisconnect-Function.
| CALL "SQLDisconnect" USING
| BY VALUE Hdbc
| RETURNING SQL-RC
| IF SQL-RC = SQL-SUCCESS-WITH-INFO
| THEN
| DISPLAY SQL-stmt " successful with information"
| ELSE
| DISPLAY SQL-stmt " failed"
| END-IF
| ELSE
| \ - indicate SQLGetDiagField failed - \
| DISPLAY "SQLGetDiagField failed with return code of: "
| SQL-RC
| END-IF
| IF SQL-RC = SQL-SUCCESS
| THEN
| DISPLAY "Rollback successful"
| ELSE
| DISPLAY "Rollback failed with return code of: "
| SQL-RC
| END-IF
| STOP RUN.
| \\\\\\\\\\\\\\\\\\\\\\\\\
| \ End of ODBC3P.CPY \
| \\\\\\\\\\\\\\\\\\\\\\\\\
Before you begin creating COBOL shared libraries, you should understand the differ-
ences between static linking and shared libraries.
The primary advantage of static linking is that you can create self-contained, inde-
pendent programs. In other words, the executable program consists of one part that
you need to keep track of. The disadvantages of static linking are as follows:
Linked external programs are built into the executable files, making these files
larger.
The behavior of executable files cannot be changed without re-linking.
External called programs cannot be shared, requiring duplicate copies of programs
to be loaded in memory if more than one calling program needs to access them.
Shared libraries are typically used to provide common functions that can be used by a
number of programs. For example, shared libraries can be used to implement subpro-
gram packages, subsystems, and interfaces to other programs. Shared libraries are
also used to create object-oriented class libraries (see Chapter 13, “Writing Object-
Oriented Programs” on page 222).
You can dynamically link with the supplied run-time shared libraries as well as with your
own COBOL shared libraries.
Terminology Notes
If you are new to AIX, you might find the terminology used to discuss shared libraries
confusing.
Keep in mind that a shared library is, above all, a library of functions. Even if there is
only one function provided by the shared library (as in the example provided in this
chapter), a shared library's purpose is to serve as a repository of frequently-used func-
tions.
Because outermost programs in the shared library are part of a library of programs,
each program is referred to as a subprogram in the shared library. Even if a shared
library provides only one program, that program is considered a subprogram of the
shared library.
The linker resolves these external references. If it finds a reference to external subpro-
grams in an import file, the code for the external subprogram is in a shared library. To
resolve external reference to shared libraries, the linker adds information to the execut-
able file that tells the loader where to find the shared library code when the executable
file is loaded.
Not all references to shared libraries by COBOL calls are resolved by the linker: CALL
identifier and CALL literal with the DYNAM option are resolved by COBOL when the
CALL is executed.
IDENTIFICATION DIVISION.
PROGRAM-ID. alpha.
\
ENVIRONMENT DIVISION.
CONFIGURATION SECTION.
\
DATA DIVISION.
WORKING-STORAGE SECTION.
ð1 hello1 pic x(3ð) value is "message from alpha to beta".
ð1 hello2 pic x(3ð) value is "message from alpha to gamma".
\
\
PROCEDURE DIVISION.
display "alpha begins"
call "beta" using hello1
display "alpha after beta"
call "gamma" using hello2
display "alpha after gamma"
goback.
IDENTIFICATION DIVISION.
PROGRAM-ID. beta.
\
ENVIRONMENT DIVISION.
\
DATA DIVISION.
WORKING-STORAGE SECTION.
\
Linkage section.
ð1 msg pic x(3ð).
\
PROCEDURE DIVISION using msg.
DISPLAY "beta gets msg=" msg.
goback.
IDENTIFICATION DIVISION.
PROGRAM-ID. gamma.
\
ENVIRONMENT DIVISION.
CONFIGURATION SECTION.
\
DATA DIVISION.
WORKING-STORAGE SECTION.
\
Linkage section.
ð1 msg pic x(3ð).
\
PROCEDURE DIVISION using msg.
DISPLAY "gamma gets msg=" msg.
goback.
The simplest method of running these programs is to compile them into a single module
using the command
cob2 -o m_abg alpha.cbl beta.cbl gamma.cbl
We will repeat this example, but this time we put beta and gamma in a shared library
and alpha in a module that uses the library.
The first step is to create a file which we call bg.exp that defines the symbols the
shared library exports:
--------------------- bg.exp --------------------------
#!
\ symbols exported by shared library libbg.a
BETA
GAMMA
These names have to be given in upper case since the COBOL default is to use upper
case names for external symbols. The compile time option PGMNAME(MIXED) can be
used if mixed case names are needed.
Now we combine beta and gamma into a shared object called sh_bg:
cob2 -o sh_bg beta.cbl gamma.cbl -bE:bg.exp -bM:SRE -bnoentry
-o sh_bg beta.cbl gamma.cbl are the usual arguments to cob2 to name the output
module sh_bg and to compile and link beta.cbl and gamma.cbl.
-bE:bg.exp is an instruction to the link command to export the symbols named in
bg.exp.
-bM:SRE tells the link command to make the output module a shared re-entrant
object.
-bnoentry tells the linker that this object does not have a main entry point (it will be
entered at BETA and GAMMA).
sh_bg can be used immediately but you may have several of these shared objects and
it is convenient to put them in a library:
ar qv libbg.a sh_bg
Now you can re-compile alpha, this time using the shared library:
cob2 -o m_alpha alpha.cbl -L. libbg.a
or alternatively you can use
cob2 -o m_alpha alpha.cbl -L. -lbg
-lxxx is a standard AIX convention for libxxx.c. The -L. tells the linker that libbg.a
is in the current directory. It is safer to specify the directory in full, for example
cob2 -o m_alpha alpha.cbl -L/usr/jane/libraries -lbg
The -L. form only works if m_alpha and libbg.a are both in the current directory.
#
#
all: m_abg libbg.a m_alpha
clean:
rm -f m_abg m_alpha sh_bg libbg.a \.lst
-------------------------------------------------------------------------
We included an rm command to remove the old copy of libbg.a and to remove sh_bg
once we are finished with it.
Executing the command m_abg or the command m_alpha gives the same output.
Note that shared libraries are widely used in AIX. The COBOL run-time is in several
shared libraries. The C run-time is in several shared libraries. Shared libraries pro-
vided a convenient and efficient way of packaging applications.
If you intend to use shared libraries, you should read the relevant parts of the AIX
online or printed documents.
See the section on Shared Libraries in AIX Version 4.1, General Programming
Concepts; Writing and Debugging Programs (SC23-2533)
Further information in the AIX Commands Reference
Figure 97 on page 393 and Figure 98 on page 393 show the source code for the two
programs.
Identification Division.
Program-id. dl1.
\
Environment Division.
Configuration Section.
Input-Output Section.
File-control.
\
Data Division.
File Section.
Working-storage Section.
ð1 var pic x(1ð).
Linkage Section.
\
Procedure Division.
move "Dl1A" to var.
display "Calling " var.
call var.
move "dl1a " to var.
display "Calling " var.
call var.
stop run.
End program dl1.
IDENTIFICATION DIVISION.
PROGRAM-ID. dl1a.
\
ENVIRONMENT DIVISION.
CONFIGURATION SECTION.
OBJECT-COMPUTER. ANY-THING.
\
DATA DIVISION.
WORKING-STORAGE SECTION.
77 num pic 9(4) binary value is zero.
\
PROCEDURE DIVISION.
LA-START.
display "COBOL DL1A function." upon console.
add 11 to num.
display "num = " num
goback.
Since the target file name of a CALL identifier must match the name of the program,
you have to generate the executable module in the above example as DL1A, not dl1a.
Figure 99 on page 395, Figure 100 on page 395, and Figure 101 on page 396 show
the source code for the programs.
17 The default library is determined by the -lcob2s and -lcob2_r command flags. Flag -lcob2_r tells the linker to use libcob2s.a;
-lcob2_r tells the linker to use libcob2_r.a.
cbl pgmname(longmixed)
\ dl6:
\ - call C function - dl6a executable
\ - call "dl6b" with pgmname(mixed)
Identification Division.
Program-id. dl6.
\
Environment Division.
Configuration Section.
Input-Output Section.
File-control.
\
Data Division.
File Section.
Working-storage Section.
ð1 var pic x(1ð).
Linkage Section.
\
Procedure Division.
move "dl6a" to var.
display "Calling " var.
call var.
move "dl6a" to var.
display "Calling " var.
call var.
move "dl6b" to var.
display "Calling " var.
call var.
move "dl6b" to var.
display "Calling " var.
call var.
stop run.
End program dl6.
void dl6a() {
static int n = 123;
printf("C dl6a function.\n");
n = n \ 1ð;
printf("n = %d\n", n);
}
cbl pgmname(longmixed)
IDENTIFICATION DIVISION.
PROGRAM-ID. "dl6b".
\
ENVIRONMENT DIVISION.
CONFIGURATION SECTION.
OBJECT-COMPUTER. ANY-THING.
\
DATA DIVISION.
WORKING-STORAGE SECTION.
77 num pic 9(4) binary value is zero.
\
PROCEDURE DIVISION.
LA-START.
display "COBOL dl6b function." upon console.
add 111 to num.
display "num = " num
goback.
The following illustration shows the relationships between processes, threads, run-units,
and program invocation instances.
Thread 1 Thread 2
COBOL PL/I COBOL
program A program program A
COBOL COBOL Program
program program invocation
A X instances
COBOL C COBOL
program B program program B
COBOL COBOL
program program COBOL COBOL COBOL
B Y program C program A program C
same
• program
• • runs in • •
• • • •
• separate • •
threads
COBOL
run-unit
COBOL does not directly support initiating or managing program threads. However,
COBOL programs can run as threads in multithreaded environments. In other words,
COBOL programs can be invoked by other applications such that they are running in
multiple threads within a process or as multiple program invocation instances within a
thread. This enables COBOL programs to run in multithreading environments like the
Distributed Computing Environment (DCE).
This remainder of this chapter contains information that will help you prepare your
COBOL programs for multithreaded environments.
Caution: Do not confuse multiprocessing or multithreading with “multitasking,” which is
generally used to describe the external behavior of applications. That is, the operating
system appears to be running more than one application simultaneously. Multitasking
has no relevance in this discussion.
The following table summarizes the reference and state scope of various COBOL lan-
guage elements.
Figure 103. Reference and State Scope for Language Elements in a Multithreading Environment
Language Element Reference Scope State Scope
ADDRESS-OF special register Same as associ- Program invocation
ated record instance
Files Run-unit Run-unit
Index data Program Program invocation
instance
LENGTH of special register Same as associ- Same as associated
ated identifier identifier
LINAGE-COUNTER special register Run-unit Run-unit
LINKAGE-SECTION data Run-unit Based on scope of
underlying data.
LOCAL-STORAGE data Within the thread Program invocation
instance
RETURN-CODE Run-unit Program invocation
instance
SORT-CONTROL, SORT-CORE-SIZE, Run-unit Program invocation
SORT-RETURN, TALLY special registers instance
WHEN-COMPILED special register Run-unit Run-unit
WORKING-STORAGE data Run-unit Run-unit
If you have resources with run-unit scope, and you want those resources to be isolated
within an individual program invocation instance (for example, programs with individual
copies of data), define the data in the local storage section so that it will have program
invocation instance scope.
Because the storage associated with these language elements is program invocation
instance scoped, data is protected from access across threads and you do not have to
concern yourself with access synchronization. However, this data cannot be shared
between invocations of programs unless it is explicitly passed.
The default option is NOTHREAD. For more information about the THREAD compiler
option, see “THREAD” on page 179.
INITIAL PROGRAM
RERUN
Segmentation module
STOP literal statement
STOP RUN
For considerations in using the LINKAGE SECTION with recursive calls, see “With
Recursion or Multithreading” on page 22.
EXIT PROGRAM
EXIT PROGRAM from the first program of a thread terminates that thread. EXIT
PROGRAM returns to the caller of the program without terminating the thread in all
other cases. EXIT PROGRAM from a main program is treated as a comment.
GOBACK
Same as EXIT PROGRAM, except that GOBACK from a main program terminates
the thread.
If it can be determined that there are no other COBOL programs active in the run
unit, the COBOL run unit termination process (including closing all open COBOL
files) is performed on the GOBACK from the first program of this thread. This
determination can be made if all COBOL programs invoked within the run unit
have returned to their invokers via GOBACK or EXIT PROGRAM.
Examples on when this determination cannot be made are:
A thread with one or more active COBOL programs was terminated (for
example, because of an exception or via pthread_exit).
A longjmp() was executed which resulted in collapsing active COBOL pro-
grams in the invocation stack.
In general, it is recommended that the programs initiating and managing multiple
threads use the COBOL pre-initialization interface.
Pre-initialization
If your program initiates multiple COBOL threads (for example, your C program
calls COBOL programs to carry out I/O), do not assume the COBOL programs
will “clean up” their environment. Particularly, do not assume that files will be
automatically closed. You should pre-initialize the COBOL environment so that
your application can control the COBOL “clean-up” (see Chapter 26, “Pre-
initializing the COBOL Run-Time Environment” on page 415).
STOP RUN: There is no COBOL function that effectively does a STOP RUN in a
threaded environment. If you need this behavior, consider invoking the C exit()
function from your COBOL program and using _iwzCOBOLTerm after the run-unit
termination exit.
extern void _iwzCOBOLInit(int fcode, PFN StopFun, int \err_code, void \StopArg);
extern void _iwzCOBOLTerm(int fcode, int \err_code);
jmp_buf Jmpbuf;
int
StopFun(long \stoparg)
{
printf("Inside StopFun. Got stoparg = %d\n", \stoparg);
\stoparg = 123;
longjmp(Jmpbuf,1);
}
long StopArg = ð;
void
testrc(int rc, const char \s)
{
if (rc != ð){
printf("%s: Fatal error rc=%d\n",s,rc);
exit(-1);
}
void
pgmy()
{
pthread_t t1, t2;
int rc;
long i;
long j;
void \r1, \r2;
pthread_attr_t attr;
i = 2ððð;
rc = pthread_create( &t1, &attr, &SUBD, &i);
testrc(rc,"create 1");
j = 1ððð;
rc = pthread_create( &t2, &attr, &SUBE, &j);
testrc(rc,"create 2");
printf("threads are %x and %x\n",t1, t2);
rc = pthread_join(t1, &r1);
printf("join %x got %d\n",t1,rc);
rc = pthread_join(t2, &r2);
printf("join %x got %d\n",t2,rc);
_iwzCOBOLTerm(1, &rc);
printf( "_iwzCOBOLTerm got expect rc=ð, got rc=%d\n",rc);
}
main()
{
if (setjmp(Jmpbuf) ==ð) {
pgmy();
}
}
The sample code for subd.cbl is shown in Figure 105 on page 405.
IDENTIFICATION DIVISION.
PROGRAM-ID. "subd".
\
ENVIRONMENT DIVISION.
CONFIGURATION SECTION.
\
DATA DIVISION.
LOCAL-STORAGE SECTION.
ð1 N2 PIC 9(8) comp-5 value ð.
\
LINKAGE SECTION.
ð1 N1 PIC 9(8) comp-5.
\
PROCEDURE DIVISION using by reference n1.
perform n1 times
DISPLAY "subd gets " n1 " " n2
compute n2 = n2 + 1
end-perform
DISPLAY "subd goback with " n1 " " n2
GOBACK.
IDENTIFICATION DIVISION.
PROGRAM-ID. "sube".
\
ENVIRONMENT DIVISION.
CONFIGURATION SECTION.
\
DATA DIVISION.
LOCAL-STORAGE SECTION.
ð1 N2 PIC 9(8) comp-5 value ð.
\
LINKAGE SECTION.
ð1 N1 PIC 9(8) comp-5.
\
PROCEDURE DIVISION using by reference n1.
perform n1 times
DISPLAY "sube gets " n1 " " n2
compute n2 = n2 + 1
end-perform
DISPLAY "sube goback with " n1 " " n2
GOBACK.
The NLS support of this product includes the support for multiple code pages. The
characters represented in a supported code page can be used in COBOL names, data
definitions, literals, and in common entries.
The following list summarizes the double-byte character set (DBCS) and extended
UNIX code (EUC) code page support:
User-defined names
DBCS and EUC names are supported.
Data type
DBCS data items (with PIC G or N) are supported only if the current code page is a
DBCS code page. DBCS data items are diagnosed as errors if the code page in
effect is an ASCII or EUC code page.
Literal
DBCS literals are supported.
You can specify EUC constants as alphanumeric literals (such as to display fields).
However, no semantics sensitive to multi-byte EUC characters are supported.
Comments
DBCS and EUC comments are supported.
Collating sequence
Collating sequences for single-byte character set (ASCII and DBCS data are locale
sensitive: that is, based on the collating sequence indicated by the locale, except
for ASCII compares with a non-NATIVE collating sequence in effect).
This collating sequence rule applies to the single-byte characters whether the
single-byte characters are from an ASCII, DBCS, or EUC code page.
Since the ANSI COBOL language elements dictate the knowledge of the collating
sequence at compile time, it is expected that the locale setting in effect at the
compile time and at the application execution time are consistent.
Locale: A locale is a collection of data that encodes information about a cultural envi-
ronment. Localization is an action that establishes a cultural environment for an appli-
cation by selecting the active locale. Only one locale can be active at one time. The
active locale affects the behavior on the locale-sensitive interfaces for the entire
program. This is called the global locale model.
Usage Notes
The maximum number of characters for a user-defined word with one or more multi-
byte characters is as follows:
15 for DBCS code page.
10 for IBM_eucJP, IBM_eucKR, and IBM_eucCN.
7 for IBM_eucTW.
A DBCS or EUC user-defined word can contain both multi-byte and single-byte charac-
ters. When a character exists in both single-byte and multi-byte forms, its single-byte
and multi-byte representations will not be regarded as equivalent. For example, “A”
represented in double-bytes will not be considered to match “A” represented in a single
byte.
Support for the library-name, program-name, and text-name user-defined words with
DBCS or EUC depends on the DBCS or EUC name support of the platform. IBM
COBOL will allow double-byte or EUC characters in these names.
Additionally, you can specify any character in one of the supported code pages using
the alphanumeric literal syntax. However, such a literal is treated as alphanumeric in
COBOL language semantics (that is, semantics appropriated for single-byte characters).
The literal delimiters can be apostrophes or quotes depending on the APOST or QUOTE
compiler option setting.
The ALL literal represents all or part of the string generated by successive concat-
enations of the single-byte characters or double-byte characters comprising the literal.
The literal must be a non-numeric literal or a DBCS literal. The literal must not be a
figurative constant.
If a data item is declared with PICTURE N or G, the selected locale must indicate a
DBCS code page. In all other cases, the PICTURE characters N and G and USAGE
DISPLAY-1 are flagged as errors.
single-byte characters of a DBCS code page should not be included in a DBCS data
item.
Operations on DBCS strings not conforming to this rule might produce unpredictable
results, such as the truncation of a string at a byte position in the middle of a double-
byte character.
This rule will not be enforced at run time. For a code page with characters repres-
ented in double bytes, the following padding and truncation rules apply where
COBOL language semantics specify truncation or padding with spaces:
Padding
For operations involving DBCS data items, the padding is done using the
double-byte space characters until the data area is filled. This is based on the
number of byte positions allocated for the data area.
Where the padding may not be in the multiple of the code page width (for
example, a group item moved to a DBCS data item), the padding is done with
single-byte space characters.
Truncation
The truncation is done based on the size of the target data area on the byte
boundary of the end of that data area. It is the application program's responsi-
bility to ensure that such a truncation does not result in truncation of bytes
representing a partial double-type character.
USAGE clause
A DBCS data item is specified with USAGE DISPLAY-1. When you use PICTURE
symbol G, you must specify USAGE DISPLAY-1. When you use PICTURE symbol N,
USAGE DISPLAY-1 is implied and the USAGE clause may be omitted.
VALUE clause
The associated VALUE clause (if specified) must specify a DBCS literal or the figura-
tive constants SPACE OR SPACES.
Reference modification
For the purpose of handling reference modifications, each character in a DBCS data
item is considered to occupy the number of bytes corresponding to the code page
width (that is, 2).
Kanji class test results in testing for valid Japanese graphic characters. This includes
Katakana, Hiragana, Roman, and Kanji character sets.
The Kanji class test is done by checking the converted characters for X'41' - X'7E'
for the first byte and X'41' - X'FE' for the second byte plus the space character,
X'4040'.
DBCS class test results in testing for valid graphic characters for the code page.
The DBCS class test is done by checking the converted characters for X'41' - X'FE'
for both the first and second byte of each character plus the space character, X'4040'.
Collating Sequence
Considerations for DBCS and ASCII collating sequence are as described below. Any
comparison involving a group item will be handled based on the comparison of the byte
for byte positions in hex.
The following clauses in the SPECIAL-NAMES paragraph may be specified only if the
code page in effect is an ASCII code page:
ALPHABET clause
SYMBOLIC CHARACTER clause
CLASS clause
These clauses, if specified with a DBCS or EUC code page in effect, will be diagnosed
and treated as comments.
DBCS Collating Sequence
Data items and literals of class DBCS can be used in a relation condition with any
relational operator. Each operand must be either of class DBCS, alphabetic, or
alphanumeric (elementary or group). Note that this allows, for example, a compar-
ison of a DBCS item with an alphanumeric item. No conversion or editing is done.
No distinction is made between items of category DBCS and items of category DBCS
edited.
DBCS comparisons are performed based on the rules for non-numeric comparisons.
The comparison is based on the locale setting for the collating sequence if the oper-
ands are elementary DBCS or alphanumeric data items.
The PROGRAM COLLATING SEQUENCE clause has no effect on comparisons involving
data items of class DBCS or DBCS literals.
ASCII Collating Sequence
The ANSI COBOL rules on the PROGRAM COLLATING SEQUENCE clause and the
COLLATING SEQUENCE clause on SORT and MERGE apply.
If the collating sequence in effect is NATIVE (which is default if neither the COLLATING
SEQUENCE clause nor the PROGRAM COLLATING SEQUENCE clause is specified),
the collating sequence is based on the locale setting. This applies to SORT or
MERGE statements as well as to the program collating sequence.
Note that the collating sequence impacts the processing of the alphabetic clause (for
example, literal-1 THRU literal-2), SYMBOLIC CHARACTERS specifications, and VALUE
range specifications for Level 88 items as well as relation conditions and SORT and
MERGE statements.
Since the rules of the COBOL user-defined alphabet name and symbolic characters
assume a character-by-character collating sequence (not a collating sequence which
may depend on a sequence of multiple characters), the locale-sensitive collating is that
aspect that can be expressed by assigning a weight on each character in the code set.
Any comparisons involving a group item will be handled based on the comparison of
the byte-for-byte positions in hex.
Comments
Character strings that form comments may contain any characters, including DBCS and
EUC characters. A single DBCS or EUC character may not be split (and continued)
across multiple source lines.
Locale Sensitivity
This product is sensitive to the locale setting for the following features:
Code page selection
The locale in effect determines the code set for both compilation of source pro-
grams, including non-numeric literal values, and their execution. That is, the code
set used for compilation is based on the locale setting at compile time, and the
code set used for application program execution is based on the locale setting at
run time.
The EBCDIC code set is based on the current locale setting.
For information about locales, code sets, and converters on AIX, refer to AIX
Version 4.1, General Programming Concepts; Writing and Debugging Programs,
SC23-2533.
If more than one EBCDIC code set is applicable for the current locale, and you
want to use other than the default, then:
– Set the CHAR compiler option to EBCDIC; “CHAR” on page 151 discusses this
option.
– Set the EBCDIC_CODEPAGE to establish the EBCDIC code set applicable; see
page 131.
Messages
This applies to the message text, the date and time format, and order for XREF for
the compiler listing output and to run-time message text. The compile-time locale
is used for compiler output, the run-time setting for run-time output.
Collating sequence
Locale sensitivity for the collating sequence applies only when the collating
sequence is NATIVE; the locale has no impact on the collating sequence if
COLLSEQ(BIN) or COLLSEQ(EBCDIC) is in effect.
The collating sequence for single-byte alphanumeric characters for the program
collating sequence is based on the compile-time or run-time locale. If the PRO-
GRAMMING COLLATING SEQUENCE clause is specified in the source program, the
collating sequence is set at compile-time and is used regardless of the run-time
locale. If the collating sequence is not set using this clause, but is set using the
COLLSEQ compiler option, the run-time locale takes precedence.
The collating sequence for SORT or MERGE statements is always based on the
run-time locale.
The run-time locale-based collating sequence is always applicable to DBCS and
EUC data, independent of the COBOL source-level collating sequence specification
(which applies to single-byte alphanumeric data), except for comparisons of literals.
Comparisons of DBCS literals are based on the compile-time locale. Thus, DBCS
literals should not be used in the source program within a statement with an
implied relational condition between two DBCS literals (such as VALUE G literal1
THRU G literal2) unless the intended run-time locale is the same as the compile-
time locale.
The compile-time and run-time locale settings are assumed to be the same for
other uses of the collating sequence.
The following are not affected by the locale setting, as the ANSI COBOL Standard
defines specific COBOL language elements for controlling these items:
Decimal point and numeric separator
Currency sign
Use the interfaces described below to initialize and terminate a persistent COBOL run-
| time environment. Any DLL that contains a COBOL program used in a pre-initialized
| environment cannot be deleted until the pre-initialized environment is terminated.
If you plan to run your program in an OS/390 or VM environment, use the pre-
initialization interfaces described in IBM Language Environment for OS/390 & VM Pro-
gramming Guide.
call
Invocation of Init_routine, using language elements appropriate to the language
from which the call is being made.
Init_routine
The name of the initialization routine: _iwzCOBOLInit or IWZCOBOLINIT
routine (input)
Address of the routine to be invoked if the run unit terminates. The token argu-
ment passed to this function will be passed on to the run unit termination exit
routine. This routine, when invoked on the run unit termination, must not return to
the invoker of the routine but rather do a longjmp() or exit().
token (input)
4 byte token to be passed on to the exit routine specified in the earlier argument
when that routine is invoked on the run unit termination.
call
Invocation of Term_routine, using language elements appropriate to the language
from which the call is being made.
Term_routine
The name of the initialization routine: _iwzCOBOLTerm or IWZCOBOLTERM
The first COBOL program called following the invocation of the pre-inialization routine is
treated as a subprogram. Thus, a GOBACK from this (initial) program does not trigger
run-unit termination semantics (such as the closing of files). Note that the run unit ter-
mination (such as with STOP RUN) does free the pre-initialized COBOL environment
prior to the invocation of the run unit exit routine.
If Not Active: If your program invokes the termination routine and the COBOL envi-
ronment is not already active, the termination routine invocation has no effect on the
execution and the control is returned to the invoker with an error code of 0.
┌─5 C_PgmY
C_PgmX │ ┌────────────────────────────────┐
┌─────────────────────────┐ │ │ ... │
│ ... │ │ │ _iwzCOBOLInit ─┼──┐
│ if (setjmp(here) !=ð │ │ │ (1, C_StopIt, fdbk, here) │ │
│ { │ │ │ ... │ │
┌──┼──5 printf("STOP RUNed") │ │ │ COBOL-PgmA() ─┐ │ │
│ │ ... │ │ │ ... │ │ │
│ │ ... │ │ └───────────────┼────────────────┘ │
│ │ } │ │ │ 6
│ │ printf("setjmp done") │ │ COBOL-PgmA %──┘ _iwzCOBOLInit
│ │ C_PgmY(here) ─────────┼─┘ ┌────────────────────┐ ┌──────────────┐
│ │ ... │ │ ... │ │ ... │
│ └─────────────────────────┘ │ CALL COBOL-PgmB ─┼─┐ └──────────────┘
│ │ ... │ │
│ └────────────────────┘ │
│ COBOL-PgmB %─────────┘
│ ┌────────────┐
│ │ ... │
│ │ STOP RUN ──┼─┐
│ └────────────┘ │
│ │
│ C_StopIt %────────────────────┘
│ ┌───────────────┐
│ │ ... │
└───────────────┤ longjmp(here) │
└───────────────┘
The following example shows the use of COBOL pre-initialization. A C main program
calls the COBOL program XIO several times. The first call to XIO opens the file, the
second call writes one record, and so on. The final call closes the file. The C program
then uses C-stream I/O to open and read the file. It assumes the use of VisualAge for
C++.
To test and run the program, enter the following commands from a command shell:
xlc -c testinit.c
cob2 testinit.o xio.cbl
a.out
#ifdef _AIX
typedef int (\PFN)();
#define LINKAGE
#else
#include <os2.h>
#define LINKAGE _System
#endif
#include <stdio.h>
#include <setjmp.h>
extern void _iwzCOBOLInit(int fcode, PFN StopFun, int \err_code, void \StopArg);
extern void _iwzCOBOLTerm(int fcode, int \err_code);
extern void LINKAGE XIO(long \k);
jmp_buf Jmpbuf;
long StopArg = ð;
int LINKAGE
StopFun(long \stoparg)
{
printf("inside StopFun\n");
\stoparg = 123;
longjmp(Jmpbuf,1);
}
main()
{
int rc;
long k;
FILE \s;
int c;
if (setjmp(Jmpbuf) ==ð) {
_iwzCOBOLInit(1, StopFun, &rc, &StopArg);
printf( "_iwzCOBOLinit got %d\n",rc);
for (k=ð; k <= 4; k++) XIO(&k);
k = 99; XIO(&k);
}
else printf("return after STOP RUN\n");
printf("StopArg=%d\n", StopArg);
_iwzCOBOLTerm(1, &rc);
printf("_iwzCOBOLTerm expects rc=ð and got rc=%d\n",rc);
printf("FILE1 contains ---- \n");
s = fopen("FILE1", "r");
if (s) {
while ( (c = fgetc(s) ) != EOF ) putchar(c);
}
printf("---- end of FILE1\n");
}
Figure 108 (Part 2 of 2). Source Code for testinit.c. A C program that shows the use of pre-
initialization.
IDENTIFICATION DIVISION.
PROGRAM-ID. xio.
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
ENVIRONMENT DIVISION.
CONFIGURATION SECTION.
INPUT-OUTPUT SECTION.
FILE-CONTROL.
SELECT file1 ASSIGN TO FILE1
ORGANIZATION IS LINE SEQUENTIAL
FILE STATUS IS file1-status.
DATA DIVISION.
FILE SECTION.
FD FILE1.
ð1 file1-id pic x(5).
WORKING-STORAGE SECTION.
ð1 file1-status pic xx value is zero.
LINKAGE SECTION.
\
ð1 x PIC S9(8) COMP-5.
if x = 1 then
MOVE ALL "1" to file1-id
WRITE file1-id
end-if
if x = 2 then
MOVE ALL "2" to file1-id
WRITE file1-id
end-if
if x = 3 then
MOVE ALL "3" to file1-id
WRITE file1-id
end-if
if x = 99 then
CLOSE file1
end-if
GOBACK.
Figure 109 (Part 2 of 2). Source Code for xio.cbl. A COBOL program that shows the use of
pre-initialization.
Intrinsic Functions
COBOL provides various string- and number-manipulation capabilities that can help you
simplify your coding. For more information, see “Numeric Intrinsic Functions” on
page 39.
The following lists the date and time callable services available:
| CEECBLDY Converts character date value to COBOL integer date format. Day one
is 01 January 1601 and the value is incremented by one for each subse-
quent day. This service is similar to CEEDAYS, except that it provides
| an answer in COBOL integer date format, so that it is compatible with
ANSI COBOL intrinsic functions. The returned value from this service
should not be used with other date and time callable services.
CEEDATE Converts dates in the Lilian format back to character values.
CEEDATM Convert number of seconds to character timestamp.
CEEDAYS Convert character date values to the Lilian format. Day one is 15
October 1582 and the value is incremented by one for each subsequent
day.
CEEDYWK Provides day of week calculation.
CEEGMT Gets current Greenwich Mean Time (date and time).
CEEGMTO Gets difference between Greenwich Mean Time and local time.
CEEISEC Converts binary year, month, day, hour, second, and millisecond to a
number representing the number of seconds since 00:00:00 15 October
1582.
CEELOCT Gets current date and time.
| CEEQCEN Queries the callable services century window.
For details on individual date and time callable services, see Appendix E, “Date and
Time Callable Services Reference” on page 484.
All of the above date and time callable services allow source code compatibility with
COBOL for OS/390 & VM and COBOL for MVS & VM. There are, however, significant
differences in the way conditions are handled. See “Condition Handling” on page 424
for details.
In this example, the date and time callable service CEEDATE converts a number
representing a Lilian date in the variable argument to a date in character format which is
written to the variable result. The format of the conversion is controlled by the picture
string contained in the variable format. Information about the success or failure of the
call is returned in the variable feedback-code.
All of the date and time callable services allow the specification of a feedback code
parameter which is optional. Specify OMITTED for this parameter if you do not want the
date and time callable service to return information about the success or failure of the
call. However, if omitting this parameter, the program will abend if the callable service
does not complete successfully. See “Condition Handling” on page 424 for additional
information.
When calling a date and time callable service and you specify OMITTED for the feed-
back code, the RETURN-CODE special register is set to 0 if the service is successful but
is not altered if the service is unsuccessful. If the feedback code is not OMITTED, the
RETURN-CODE special register is always set to 0 regardless of whether the service
completed successfully.
Chapter 27. Productivity and Tuning Techniques 423
Simplifying Coding
For a description of the OMITTED phrase, see IBM COBOL Language Reference.
The date and time callable services must be invoked using the standard system linkage
convention. This can be achieved by either compiling the program using the
CALLINT(SYSTEM) compiler option (this is the default), or by using the
>>CALLINTERFACE SYSTEM compiler-directing statement.
| Note: The CALL statements used to invoke the date and time callable services must
| use a literal for the program name as opposed to an identifier. See IBM COBOL Lan-
guage Reference for details on the CALL statement.
Condition Handling
There is a significant difference in the condition handling between COBOL Set for AIX
and IBM Language Environment on the host. COBOL Set for AIX adheres to the native
COBOL condition handling scheme and does not provide the level of support in Lan-
guage Environment. If a feedback token is passed as an argument, it will simply be
returned after the appropriate information has been filled in. The caller can then
examine the contents and perform any actions, if necessary. The condition will not be
signaled. If a date and time callable service is called with the OMITTED phrase as a
substitute for the feedback code, the program will abend if the service does not com-
plete successfully.
A feedback token contains feedback information in the form of a condition token. The
condition token set by the service will be returned to the calling routine, indicating
whether the service was completed successfully or not. COBOL Set for AIX uses the
same feedback token as Language Environment which is defined as follows:
ð1 FC.
ð2 Condition-Token-Value.
COPY CEEIGZCT.
ð3 Case-1-Condition-ID.
| ð4 Severity PIC S9(4) COMP.
| ð4 Msg-No PIC S9(4) COMP.
ð3 Case-2-Condition-ID
REDEFINES Case-1-Condition-ID.
| ð4 Class-Code PIC S9(4) COMP.
| ð4 Cause-Code PIC S9(4) COMP.
ð3 Case-Sev-Ctl PIC X.
ð3 Facility-ID PIC XXX.
| ð2 I-S-Info PIC S9(9) COMP.
The following describes what each field will contain and identifies any differences with
IBM Language Environment on the host:
Severity This is the severity number with the following possible values:
0 Information only (or, if the entire token is zero, no information).
1 Warning - service completed, probably correctly.
2 Error detected - correction attempted; service completed, perhaps
incorrectly.
3 Severe error - service not completed.
4 Critical error - service not completed.
Msg-No This is the associated message number. See Appendix F, “Run-Time
Messages” on page 532 for additional information.
Case-Sev-Ctl This field will always contain the value 1.
Facility-ID This field will always contain the characters CEE.
I-S-Info This field will always contain the value 0.
A sample COPY file is provided which defines the condition tokens. The file name is
CEEIGZCT.CPY. The condition tokens contained herein are equivalent to those pro-
vided with Language Environment, except that character representations are in ASCII
instead of EBCDIC. This must be taken into account if comparing the condition tokens
with Language Environment.
The descriptions of the individual callable services include a listing of the possible sym-
bolic feedback codes that might be returned in the feedback code output field specified
on invocation of the service. In addition to these, the symbolic feedback code CEE0PD
might be returned for any callable service. See message IWZ0813S for details.
All date and time callable services are based on the Gregorian calendar. Date vari-
ables associated with this calendar have architectural limits. These limits are:
Starting Lilian date The beginning of the Lilian date range is Friday 15 October
1582, the date of adoption of the Gregorian calendar. Lilian
dates preceding this date are undefined. Therefore:
Day zero is 00:00:00 14 October 1582
Day one is 00:00:00 15 October 1582
All valid input dates must be after 00:00:00 15 October 1582.
End Lilian date The end Lilian date range is set to 31 December 9999. Lilian
dates following this date are undefined. The reason for this limit
is a 4-digit year.
output. Figure 110 on page 426 and Figure 111 on page 427 define the supported
picture character terms and string values.
Figure 110 (Page 1 of 2). Picture Character Terms Used in Picture Strings for Date and Time Services
Picture
Terms Explanations Valid Values Notes
Y 1-digit year 0-9 Y valid for output only.
YY 2-digit year 00-99 YY assumes range set by
YYY 3-digit year 000-999 CEESCEN.
ZYY 3-digit year within era 1-999 YYY/ZYY used with <JJJJ>, <CCCC>
YYYY 4-digit year 1582-9999 and <CCCCCCCC>.
<JJJJ> Japanese era name in DBCS Heisei Affects YY field: if <JJJJ> speci-
characters (X'95BD9ðAC') fied, YY means the year within
Showa Japanese era, for example, 1988
(X'8FBA9861') equals Showa 63. See example
Taisho in Figure 111 on page 427.
(X'91E59ðB3')
Meiji
(X'96BE8EA1')
<CCCC> Republic of China (ROC) era MinKow Affects YY field: if <CCCC> speci-
<CCCCCCCC> name in DBCS characters (X'8D8196CD') fied, YY means the year within
ChuHwaMinKow ROC era, for example, 1988
(X'8C839ADC8D8196CD') equals Minkow 77. See example
in Figure 111 on page 427.
MM 2-digit month 01-12
ZM 1- or 2-digit month 1-12 For output, leading zero sup-
pressed. For input, ZM treated as
MM.
RRRR Roman numeral month I␣␣␣-XII␣ (Left justified) For input, source string is folded
RRRZ to uppercase. For output, upper-
case only. I=Jan, II=Feb, ...,
XII=Dec.
MMM 3-char month, uppercase JAN-DEC For input, source string always
Mmm 3-char month, mixed case Jan-Dec folded to uppercase. For output,
MMMM...M 3-20 char mo., uppercase JANUARY␣␣-DECEMBER␣ M generates uppercase and m gen-
Mmmm...m 3-20 char mo., mixed case January␣␣-December␣ erates lowercase. Output is
MMMMMMMMMZ trailing blanks suppressed JANUARY-DECEMBER padded with blanks (␣) (unless Z
Mmmmmmmmmz trailing blanks suppressed January-December specified) or truncated to match
the number of Ms, up to 20.
DD 2-digit day of month 01-31 For output, leading zero is always
ZD 1- or 2-digit day of mo. 1-31 suppressed. For input, ZD treated
DDD Day of year (Julian day) 001-366 as DD.
HH 2-digit hour 00-23
ZH 1- or 2-digit hour 0-23 For output, leading zero sup-
pressed. For input, ZH treated as
HH. If AP specified, valid values
are 01-12.
MI Minute 00-59
SS Second 00-59
9 Tenths of a second 0-9 No rounding.
99 Hundredths of a second 00-99
999 Thousandths of a second 000-999
Figure 110 (Page 2 of 2). Picture Character Terms Used in Picture Strings for Date and Time Services
Picture
Terms Explanations Valid Values Notes
AP AM/PM indicator AM or PM AP affects HH/ZH field. For input,
ap am or pm source string always folded to
A.P. A.M. or P.M. uppercase. For output, AP gener-
a.p. a.m. or p.m. ates uppercase and ap generates
lowercase.
W 1-char day-of-week S, M, T, W, T, F, S For input, Ws are ignored. For
WWW 3-char day, uppercase SUN-SAT output, W generates uppercase
Www 3-char day, mixed case Sun-Sat and w generates lowercase.
WWW...W 3-20 char day, uppercase SUNDAY␣␣␣-SATURDAY␣ Output padded with blanks
Www...w 3-20 char day, mixed case Sunday␣␣␣-Saturday␣ (unless Z specified) or truncated
WWWWWWWWWZ Trailing blanks suppressed SUNDAY-SATURDAY to match the number of Ws, up to
Wwwwwwwwwz Trailing blanks suppressed Sunday-Saturday 20.
All others Delimiters X'01'-X'FF' For input, treated as delimiters
(X'00' is reserved for “internal” between the month, day, year,
use by the date and time callable hour, minute, second, and fraction
services) of a second. For output, copied
exactly as is to the target string.
Note:
Blank characters are indicated by the symbol ␣.
Figure 111 (Page 1 of 2). Examples of Picture Strings Recognized by Date and Time Services
Picture Strings Examples Notes
YYMMDD 880516
YYYYMMDD 19880516
YYYY-MM-DD 1988-05-16 1988-5-16 would also be valid input.
<JJJJ> YY.MM.DD Showa 63.05.16 Showa is a Japanese Era name. Showa 63
equals 1988.
<CCCC> YY.MM.DD MinKow 77.05.16 MinKow is an ROC Era name. MinKow 77
equals 1988.
MMDDYY 050688
MM/DD/YY 05/06/88
ZM/ZD/YY 5/6/88
MM/DD/YYYY 05/06/1988
MM/DD/Y 05/06/8 1-digit year format (Y) valid for output only
DD.MM.YY 09.06.88
DD-RRRR-YY 09-VI -88
DD MMM YY 09 JUN 88
DD Mmmmmmmmmm YY 09 June 88
ZD Mmmmmmmmmz YY 9 June 88 Z suppresses zeros/blanks
Mmmmmmmmmz ZD, YYYY June 9, 1988
ZDMMMMMMMMzYY 9JUNE88
YY.DDD 88.137 Julian date
YYDDD 88137
YYYY/DDD 1988/137
Figure 111 (Page 2 of 2). Examples of Picture Strings Recognized by Date and Time Services
Picture Strings Examples Notes
YYMMDDHHMISS 880516204229 Timestamp—valid only for CEESECS and
YYYYMMDDHHMISS 19880516204229 CEEDATM. If used with CEEDATE, time
YYYY-MM-DD HH:MI:SS.999 1988-05-16 20:42:29.046 positions are filled with zeros. If used with
WWW, ZM/ZD/YY HH:MI AP MON, 5/16/88 08:42 PM CEEDAYS, HH, MI, SS, and 999 fields are
Wwwwwwwwwz, DD Mmm YYYY, Monday, 16 May 1988, 8:42 PM ignored.
ZH:MI AP
Note: Lowercase characters must be used only for alphabetic picture terms.
Figure 112. Japanese Eras Used by Date/Time Services when <JJJJ> Specified
First Date of Era Name in Japanese
Japanese Era Era Name DBCS Code Valid Year Values
1868-09-08 Meiji X'96BE8EA1' 01-45
1912-07-30 Taisho X'91E59ðB3' 01-15
1926-12-25 Showa X'8FBA9861' 01-64
1989-01-08 Heisei X'95BD9ðAC' 01-999 (01 = 1989)
Figure 113. Republic of China Eras Used by Date/Time Services when <CCCC> or <CCCCCCCC> Specified
First Date of Era Name in Chinese
ROC Era Era Name DBCS Code Valid Year Values
1912-01-01 MinKow X'96BE8EA1' 01-999 (77 = 1988)
ChuHwaMinKow X'8C839ADC8D8196CD'
Performing Calculations
The date and time callable services store dates as fullword binary integers and
timestamps as doubleword floating-point values, formats that permit you to perform
arithmetic calculations on date and time values in a simple and efficient manner. This
eliminates the need to write special subroutines that use services outside of the lan-
guage library for your application in order to perform these calculations. The following
is a generic example of how you can use date and time callable services to convert a
date to a different format and perform a simple calculation on the formatted date:
CALL CEEDAYS USING dateof_hire, 'YYMMDD', doh_lilian, fc.
CALL CEELOCT USING todayLilian, today_seconds, today_Gregorian, fc.
COMPUTE servicedays = today_Lilian - doh_Lilian.
COMPUTE serviceyears = service_days / 365.25.
In the example, you want to calculate the number of years of service for an employee
in your organization, and are using the original date of hire in the format YYMMDD to
make the calculations. Use the CEEDAYS (Convert Date to Lilian Format) service to
convert these dates to a Lilian format.
The CEELOCT (Get Current Local Time) service is called next to get the current local
time. doh_Lilian is then subtracted from today_Lilian (the number of days from the
beginning of the Gregorian calendar to the current local time) to calculate the employ-
ee's total number of days of employment. The final calculation divides that number by
365.25 to get the number of service years.
One hundred years, in 1997 spanning from 1917 to 2016, is the default century window
for the date and time callable services. For example, in 1997 years 17 through 99 are
recognized as 1917-1999, and years 00 through 16 are recognized as 2000-2016. In
1998, years 18 through 99 are recognized as 1918-1999, and years 00 through 17 are
recognized as 2000-2017.
By year 2080, all 2-digit years would be recognized as 20xx. In 2081, 00 would be
recognized as year 2100.
Some applications may need to set up a different 100-year interval. For example,
banks often deal with 30-year bonds, which could be due 01/31/20. The CEESCEN
callable service (see Appendix E, “Date and Time Callable Services Reference” on
page 484) allows you to change the century window.
A companion service, CEEQCEN, queries the current century window. This allows a
subroutine, for example, to use a different interval for date processing than the parent
routine. Before returning, the subroutine would reset the interval back to the way it was
previously, as shown in Figure 114 on page 430.
.
.
.
WORKING-STORAGE SECTION
77 OLDCEN PIC S9(9) COMP.
77 TEMPCEN PIC S9(9) COMP.
77 QCENFC PIC X(12).
PROCEDURE DIVISION.
GOBACK.
Figure 115 on page 431 shows a sample COBOL program that uses date and time
callable services to format and display a date from the results of a COBOL ACCEPT
statement.
CBL QUOTE
ID DIVISION.
PROGRAM-ID. HOHOHO.
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
\ FUNCTION: DISPLAY TODAY'S DATE IN THE FOLLOWING FORMAT: \
\ WWWWWWWWW, MMMMMMMM DD, YYYY \
\ \
\ For example: MONDAY, MARCH 1ð, 1997 \
\ \
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
ENVIRONMENT DIVISION.
DATA DIVISION.
WORKING-STORAGE SECTION.
ð1 CHRDATE.
ð5 CHRDATE-LENGTH PIC S9(4) COMP VALUE 1ð.
ð5 CHRDATE-STRING PIC X(1ð).
ð1 PICSTR.
ð5 PICSTR-LENGTH PIC S9(4) COMP.
ð5 PICSTR-STRING PIC X(8ð).
PROCEDURE DIVISION.
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
\ USE DATE/TIME CALLABLE SERVICES TO PRINT OUT \
\ TODAY'S DATE FROM COBOL ACCEPT STATEMENT. \
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
ACCEPT CHRDATE-STRING FROM DATE.
DISPLAY "\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\".
DISPLAY FORMATTED-DATE.
DISPLAY "\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\".
STOP RUN.
Optimization
The COBOL optimizer is activated when you use the OPTIMIZE compiler option. The
purpose of the OPTIMIZE compiler option is to do the following:
Eliminate unnecessary transfers of control or simplify inefficient branches, including
those generated by the compiler that are not evident from looking at the source
program.
Simplify the compiled code for a CALL statement to a contained (nested) program.
Where possible, the optimizer places the statements inline, eliminating the need for
linkage code. This optimization, known as procedure integration, is further dis-
cussed in “Contained Program Procedure Integration.” If procedure integration
cannot be done, the optimizer uses the simplest linkage possible (perhaps as few
as two instructions) to get to and from the called program.
Eliminate duplicate computations (such as subscript computations and repeated
statements) that have no effect on the results of the program.
Eliminate constant computations by performing them when the program is com-
piled.
Eliminate constant conditional expressions.
Aggregate moves of contiguous items (such as those that often occur with the use
of MOVE CORRESPONDING) into a single move. Both the source and target must
be contiguous for the moves to be aggregated.
The FULL suboption requests that the compiler discard any unreferenced data
items from the DATA DIVISION, and suppress generation of code to initialize these
data items to their VALUE clauses.
To see how the optimizer works on your program, compile it with and without the OPTI-
MIZE option and then compare the generated code. (Use the LIST compiler option to
request the assembler language listing of the generated code.)
For unit testing your programs, you might find it easier to debug code that has not been
optimized. But when the program is ready for final test, specify OPTIMIZE, so that the
tested code and the production code are identical. You might also want to use the
option during development, if a program is used frequently without recompilation.
However, the overhead for OPTIMIZE might outweigh its benefits if you re-compile fre-
quently, unless you are using the assembler language expansion (LIST option) to fine
tune your program.
Program Size: If the contained programs are invoked by several CALL statements and
replace each such CALL statement, the program may become larger. The optimizer
limits this increase to no more than 50 percent, after which it no longer uses procedure
integration. The optimizer then chooses the next best optimization for the CALL state-
ment; the linkage overhead can be as few as two instructions.
The ON ALL PROCEDURES option of the USE FOR DEBUGGING statement generates
extra code at each transfer to every procedure name. It can be very useful for debug-
ging, but can make the program significantly larger as well as substantially inhibit opti-
mization.
Additionally, compiler options can also have an effect (see “Compiler Options” for
details).
Compiler Options
You might have a customized system that requires certain options for optimum perform-
ance. Check with your systems programmer to ensure that installed options are not
required before changing defaults. You can see what your system defaults are by
issuing ERRMSG. For instructions on issuing ERRMSG, see “Generating a List of All
Compiler Error Messages” on page 145.
The tuning methods and performance information discussed here are intended to help
you select from various COBOL options for compiling your programs.
Important
Make sure that COBOL serves your needs. Please confer with system program-
mers on how you should tune your COBOL programs. Doing so will ensure that
the options you choose are appropriate for programs being developed at your site.
Performance advantages
Using DYNAM means easier subprogram maintenance because
the application will not have to be link-edited again if the sub-
program is changed.
When using the DYNAM option, you can free virtual storage
that is no longer needed by issuing the CANCEL statement.
Performance disadvantages
You pay a slight performance penalty using DYNAM because
the call must go through a Language Environment routine.
Reference information
For a description of the DYNAM option, see “DYNAM” on
page 156.
OPTIMIZE Use the OPTIMIZE compiler option to ensure your code is optimized for
better performance.
Performance advantages
Generally results in more efficient run-time code.
Performance disadvantages
OPTIMIZE requires more processing time for compiles than
NOOPTIMIZE.
Reference information
For further description of OPTIMIZE, see “The OPTIMIZE Com-
piler Option” on page 432. See “OPTIMIZE” on page 171 for
the OPTIMIZE syntax.
Usage notes
NOOPTIMIZE is generally used during program development
when frequent compiles are necessary, and it also allows for
easier debugging. For production runs, however, using OPTI-
MIZE is recommended.
SSRANGE The SSRANGE option verifies that all table references and reference modifi-
cation expressions are in proper bounds.
Performance advantages
No performance advantages.
Performance disadvantages
SSRANGE generates additional code for verifying table refer-
ences.
Reference information
For SSRANGE syntax, see “SSRANGE” on page 178.
Usage notes
In general, if you only need to verify the table references a few
times in the application instead of at every reference, coding
your own checks may be faster than using the SSRANGE com-
piler option. SSRANGE can be turned off at run time with the
CHECK(OFF) run-time option. For performance-sensitive appli-
| This chapter outlines a number of approaches you can adopt to resolve problems of
| this nature, and points to facilities available in the COBOL compiler and in the date and
| time callable services that can assist you.
| For more information on the new features of the COBOL language that can help
| resolve date-related problems, see Chapter 29, “Using the Millennium Language
| Extensions” on page 446.
| For more information about Year 2000 issues, and IBM software products that can help
| you identify and resolve their related problems, visit the website at:
| http://www.software.ibm.com/year2000.
The field expansion method is a long-term solution and is the recommended approach
| to addressing the Year 2000 problem. To achieve this field expansion, you need to
| develop a program to read in the old data, convert it, and write it back into a copy of
| the original file or data base that has been expanded to hold the 4-digit year data. All
| new data would then go into the new file or database. All of your application programs
| that use those files and databases need to be changed to act on the new 4-digit year
| date fields instead of the 2-digit year fields.
| Your conversion program needs to use a century window when expanding 2-digit years
| to 4 digits, to ensure that the output dates are correct.
| There are several ways to use COBOL Set for AIX to help convert your databases or
| files from 2-digit year dates to 4-digit year dates, with a century window being taken
| into account:
| DATEPROC processing
| Use the DATEPROC compiler option and the DATE FORMAT clause to define
| date fields, and use MOVE statements to expand the dates based on the
| century window specified by the YEARWINDOW compiler option. For example:
| ð5 Date-Short Pic x(6) Date Format yyxxxx.
||| ...
| ð5 Date-Long Pic x(8) Date Format yyyyxxxx.
|| ..
| .
| Move Date-Short to Date-Long.
| For more information, see Chapter 29, “Using the Millennium Language
| Extensions” on page 446.
| COBOL coding
| You can move a 2-digit year date field to an expanded receiving field, and “hard
| code” a century component as part of the move. For example:
| ð5 Date-Short Pic x(6) Date Format yyxxxx.
|| ..
| .
| ð5 Date-Long Pic x(8) Date Format yyyyxxxx.
|| ..
| .
| String "19" Date-Short Delimited by Size
| Into Date-Long.
| The hard-coded century component assumes a century window of 1900–1999 in
| this example, but you can add code to recognize different date ranges and
| assign a different century based on the value of Date-Short. For example, the
| following code expands the date based on a century window of 1930–2029:
Advantages:
The code changes are straightforward.
Minimum testing is required and possibly no need for simulation of future dates on
dedicated machines.
Faster resulting code.
The issue is addressed once and for all.
Maintenance will become cheaper.
Disadvantages:
Databases and files must be changed.
| In your application progams, you need to add some data items to hold the 4-digit year
| dates, and some processing logic to expand and contract the date fields. The resultant
| program will be structured like this:
| 1. Read the input files with 2-digit year dates.
| 2. Declare “shadow” data items that contain 4-digit year dates, and expand the 2-digit
| year fields into these work fields.
| 3. Use the 4-digit year dates for all date processing in the program.
| 4. Copy (window) the 4-digit year date fields back to 2-digit format for the output
| process.
| 5. Write the 2-digit year dates to the output files.
| There are several ways to use COBOL Set for AIX to achieve the field expansion and
| windowing needed for this solution.
| and take some error action if it is not. For example, if the 4-digit year field contains
| 2010 and the century window is 1905–2004, the date is outside the century
| window, and to simply store the last 2 digits would be incorrect.
| With the DATEPROC compiler option and the DATE FORMAT clause, copy the
| expanded date fields back to windowed date fields. If you use a COMPUTE state-
| ment to do this, you can use the ON SIZE ERROR phrase to ensure that the date
| remains within the century window, or to take some action if it doesn't. For details,
| see “ON SIZE ERROR Phrase” on page 456.
| Advantages:
| Databases and files need not be changed.
| The code changes are straightforward.
| Good interim step towards a full field expansion solution.
| Faster resulting code.
| Disadvantages:
| Some risk of data corruption.
| Short- to medium-term solution only.
| There are several ways to use COBOL Set for AIX to help you achieve this:
| Use the DATEPROC compiler option and the DATE FORMAT clause to define date
| fields. This provides an automated windowing capability using the century window
| defined by the YEARWINDOW compiler option.
| For more information, see Chapter 29, “Using the Millennium Language
| Extensions” on page 446.
| Use the intrinsic functions DATE-TO-YYYYMMDD, DAY-TO-YYYYDDD, and
| YEAR-TO-YYYY to interpret date fields based on a century window. The century
| window is specified as an argument to the intrinsic function. For example:
| If Function YEAR-TO-YYYY (Current-Year, 48) Greater Than
| Function YEAR-TO-YYYY (Due-Year, 48) Then
| Display "Due date has passed."
| End-If.
| In this example, the century window begins 48 years prior to the year at the time
| the program is being run. If the program is running in 1998, then the century
| window is 1950–2049. This would allow a Current-Year value of 00 to be “greater”
| than a Due-Year value of 99.
| Insert IF statements around the references to date fields in your program, to deter-
| mine how to apply a century component. For example, the following code imple-
| ments a century window of 1940–2039:
You cannot use the century window forever because a 2-digit year can only be unique
in a given 100-year period. Over time you will need more than 100 years for your data
window—in fact, many companies need more than 100 years now. For example, the
century window cannot solve the problem of trying to figure out how old a customer is if
the customer is older than 100 years and you only have 2-digit year dates. Another
example is sorting. All of the records that you want to sort by date must have 4-digit
| year dates. For these issues and others you need to adopt The Full Field Expansion
| Solution.
Advantages:
No database or file changes.
| In addition, if you do not use the DATEPROC and DATE FORMAT method, the following
| disadvantages apply:
| Risk of performing incorrect translations.
| Code changes are more error-prone and require more expertise.
| Increased maintenance costs.
| For those dates that are still in 2-digit year form, you can use internal bridging or
| century windowing, both of which are described in detail in “The Internal Bridging
| Solution” on page 439, and “The Century Window Solution” on page 440, respectively.
| You change the data descriptions for dates that you have expanded to 4-digit year
| form, and then use any of the techniques described in “The Full Field Expansion
| Solution” for processing them.
| The mixed solution has the advantages and disadvantages of the individual techniques
| that are discussed in these sections. In addition, the mixed solution has the advantage
| that files and databases can be changed as convenient, and kept unmodified otherwise.
This solution is the least desirable way to address the Year 2000 problem.
Advantages:
Uses existing 2-byte date fields.
Disadvantages:
Performance will be slower due to increased logic.
More testing is required to validate changes and simulation of future dates on dedi-
cated machines is essential.
Very difficult to manage across applications.
Code changes are more error-prone and require more expertise.
Increased maintenance costs.
The problem is not permanently solved and it will become necessary to change
date programs and databases to use 4-digit years eventually.
Cannot be read in dumps or listings.
Must be translated whenever externalized.
Risk of performing incorrect translations.
Integer dates are provided by COBOL intrinsic functions and by the date and time call-
able services.
This solution is not the recommended way to address the Year 2000 problem. Instead,
use the The Full Field Expansion Solution described on page 437.
Advantages:
Uses only 4 bytes to store a date.
Disadvantages:
Performance will be slower due to increased logic.
More testing is required to validate changes and simulation of future dates on dedi-
cated machines is essential.
Very difficult to manage across applications.
Code changes are more error-prone and require more expertise.
Increased maintenance costs.
The problem is not permanently solved and it will become necessary to change
date programs and databases to use 4-digit years eventually.
Cannot be read in dumps or listings.
Must be translated whenever externalized.
Risk of performing incorrect translations.
There are too many different integer format starting dates:
– CICS, OS/390, and DB2 start with January 1, 1900
– PL/I does not support integer date values
– C starts with January 1, 1970
– COBOL starts with January 1, 1601
– Date and time callable services start with October 15, 1582 (Lilian integer
dates)
There will be no problems with integer dates if conversion to and from integer is
done using the same method in the same program. There will only be problems if
the integer values are stored or passed between programs. These problems could
still be avoided by:
– Not using the value returned by CEECBLDY as input to other date and time
callable services; CEECBLDY returns an ANSI COBOL integer date that can
be used with COBOL intrinsic functions.
– Only using date and time callable services, or only COBOL intrinsic functions,
for getting and manipulating 4-digit year dates.
Note: A program can be compiled on the host using the INTDATE(LILIAN) compiler
option to provide compatibility between the Lilian date returned by CEEDAYS and
COBOL intrinsic functions. However, COBOL Set for AIX does not support the
INTDATE compiler option and such a program will therefore not produce correct
results on the workstation or PC.
| Performance Considerations
| Any implementation of a solution to the year 2000 problem will have some impact on
| the performance of your application. This section discusses some of the performance
| aspects that you should consider.
| Performance Comparison
| The following implementation methods are listed in order of least performance impact to
| most performance impact.
| Full field expansion
| The best performance can be obtained by expanding all of the dates in your
| files as a one-time task, and thereafter using the 4-digit year date fields in all
| processing.
| Mixed field expansion and DATEPROC windowing
| If the dates in your files have not yet been expanded, the best performance can
| be obtained by expanding the date fields as they are read from the files, and
| using these expanded dates in the main processing body of the program. In
| this way, the expansion process is only performed once for each date field.
| Mixed field expansion and manual windowing
| You can expand your input date fields manually, using combinations of COBOL
| coding, intrinsic functions, and callable services to apply the century window.
| This has more performance impact than DATEPROC windowing, even though the
| expansion process is still only performed once for each date field.
| DATEPROC windowing
| The millennium language extensions provide a windowing method that is
| designed to be efficient. However, the action of viewing a windowed date field
| for a COBOL IF or MOVE statement still imposes some processor overhead.
| Manual windowing
| Date windowing using COBOL IF statements adds a level of complexity to the
| program, and adds some processor overhead because of the extra COBOL
| statements. Typically the overhead of an IF statement of this form is more than
| the overhead of the automatic DATEPROC windowing process.
| Description
| The term “Millennium Language Extensions” refers collectively to the features of
| COBOL Set for AIX that are activated by the DATEPROC compiler option to help with
| Year 2000 date logic problems.
| This chapter describes how you can use these new facilities to help solve date logic
| problems in your COBOL programs.
| Getting Started
| With the millennium language extensions, you can make simple changes to your
| COBOL programs to define date fields, and the compiler recognizes and acts on those
| dates using a century window to ensure consistency.
| A century window is a 100-year interval, such as 1950–2049, within which any 2-digit
| year is unique. For windowed date fields, the century window start date is specified by
| the YEARWINDOW compiler option. When the DATEPROC option is in effect, the
| compiler applies this window to 2-digit year, or windowed, date fields in the program.
| For example, with a century window of 1930–2029, COBOL interprets 2-digit years as:
| Year values from 00 through 29 are interpreted as years 2000–2029
| Year values from 30 through 99 are interpreted as years 1930–1999
| To implement date windowing using COBOL date processing, you define the century
| window with the YEARWINDOW compiler option, and identify the date fields in your
| program with DATE FORMAT clauses. The compiler then automatically applies the
| century window to operations on those dates. It is often possible to implement a sol-
| ution in which the windowing process is fully automatic; that is, you simply identify the
| fields that contain windowed dates, and you do not need any extra program logic to
| implement the windowing.
| Use the YEARWINDOW compiler option to set the century window. There are two
| ways of doing this:
| – For a fixed window, specify a 4-digit year between 1900 and 1999 as the
| YEARWINDOW option value. For example, YEARWINDOW(1950) defines a fixed
| window of 1950–2049.
| – For a sliding window, specify a negative integer from -1 through -99 as the
| YEARWINDOW option value. For example, YEARWINDOW(-48) defines a sliding
| window that starts 48 years before the year that the program is running. So if
| the program is running in 1998, the century window is 1950–2049, and in 1999
| it automatically becomes 1951–2050, and so on. For a full description and
| syntax, see “YEARWINDOW” on page 186.
| Add the DATE FORMAT clause to the data description entries of those data items
| in the program that contain dates that you want the compiler to recognize as win-
| dowed or expanded dates. For a full description of the DATE FORMAT clause,
| see IBM COBOL Language Reference.
| To expand dates, use MOVE or COMPUTE statements to copy the contents of
| windowed date fields to expanded date fields.
| These and other approaches are discussed in conceptual terms in “Year 2000
| Solutions” on page 436. The description here concentrates on the application of
| COBOL date processing capabilities as a tool to implement the solutions.
| Basic Remediation
| The simplest method of ensuring that your programs will continue to function through
| the year 2000 is to implement a century window solution.
| With this method, you define a century window, and specify the fields that contain win-
| dowed dates. The compiler then interprets the 2-digit years in those date fields
| according to the century window.
| The following sample code shows how a program can be modified to use this automatic
| date windowing capability. The program checks whether a video tape was returned on
| time:
| CBL LIB,QUOTE,NOOPT,DATEPROC(FLAG),YEARWINDOW(-6ð)
|| ..
| .
| ð1 Loan-Record.
| ð5 Member-Number Pic X(8).
| ð5 Tape-ID Pic X(8).
| ð5 Date-Due-Back Pic X(6) Date Format yyxxxx.
| ð5 Date-Returned Pic X(6) Date Format yyxxxx.
||| ...
| If Date-Returned Greater than Date-Due-Back Then
| Perform Fine-Member.
| In this example, there are no changes to the Procedure Division from the program's
| previous version. The addition of the DATE FORMAT clause on the two date fields
| means that the compiler recognizes them as windowed date fields, and therefore
| applies the century window when processing the IF statement. For example, if Date-
| Due-Back contains “000102” (January 2, 2000) and Date-Returned contains “991231”
| (December 31, 1999), Date-Returned is less than (earlier than) Date-Due-Back, so the
| program does not perform the Fine-Member paragraph.
| Advantages:
| Fast and easy to implement.
| No change to the program's logic, therefore less testing required.
| This solution will allow your programs to function into and beyond the year 2000.
| Disadvantages:
| This should be regarded as a short-term solution, not as a permanent fix.
| There may be some performance degradation introduced by the date windowing
| functions.
| Implementation of this solution is application-dependent. It will not suit all applica-
| tions.
| Internal Bridging
| If your files and databases have not yet been converted to 4-digit year dates, you can
| use an internal bridge technique to process the dates as 4-digit years. Your program
| will be structured as follows:
| 1. Read the input files with 2-digit year dates.
| 2. Declare these 2-digit dates as windowed date fields and move them to expanded
| date fields, so that the compiler automatically expands them to 4-digit year dates.
| 3. In the main body of the program, use the 4-digit year dates for all date processing.
| 4. Window the dates back to 2-digit years.
| 5. Write the 2-digit year dates to the output files.
| This process provides a convenient migration path to a full expanded-date solution, and
| also may have performance advantages over using windowed dates. For more infor-
| mation, see “Performance Considerations” on page 444.
| Using this technique, you do not change any of the logic in the main body of the
| program. You simply use the 4-digit year date fields in Working-Storage instead of the
| 2-digit year fields in the records.
| Because you are converting the dates back to 2-digit years for output, you should allow
| for the possibility of the year being outside the century window. For example, if a date
| field contains the year 2005, but the century window is 1905–2004, then the date is
| outside the window, and simply storing it as a 2-digit year would be incorrect. To
| protect against this, you can use a COMPUTE statement to store the date, with the ON
| SIZE ERROR phrase to detect whether or not the date is within the century window.
| For more details, see “ON SIZE ERROR Phrase” on page 456.
| The following example shows how a program can be changed to implement an internal
| bridge method:
| CBL LIB,QUOTE,NOOPT,DATEPROC(FLAG),YEARWINDOW(-6ð)
|| ..
| .
| File Section.
| FD Customer-File.
| ð1 Cust-Record.
| ð5 Cust-Number Pic 9(9) Binary.
|| ..
| .
| ð5 Cust-Date Pic 9(6) Date Format yyxxxx.
| Working-Storage Section.
| 77 Exp-Cust-Date Pic 9(8) Date Format yyyyxxxx.
||| ...
| Procedure Division.
| Open I-O Customer-File.
| Read Customer-File.
| Move Cust-Date to Exp-Cust-Date.
|| ..
| .
| \=====================================================\
| \ Use expanded date in the rest of the program logic \
| \=====================================================\
|| ..
| .
| Compute Cust-Date = Exp-Cust-Date
| On Size Error Display "Exp-Cust-Date outside
| century window"
| End-Compute
| Rewrite Cust-Record.
| Advantages:
| Little change to the program logic, therefore testing is easy.
| This solution will allow your programs to function into and beyond the year 2000.
| This is a good incremental step towards a full expanded-year solution.
| Good performance.
| Disadvantages:
| Some risk of data corruption.
| The millennium language extensions allow you to progressively move towards a full
| date field expansion solution, using the following steps:
| 1. Apply the short-term (basic remediation) solution, and use this until you have the
| resources to implement a more permanent solution.
| 2. Apply the internal bridging scheme. This allows you to use expanded dates in your
| programs while your files continue to hold dates in 2-digit year form. This in turn
| will allow you to progress more easily to a full field expansion solution, because
| there will be no changes to the logic in the main body of the programs.
| 3. Change the file layouts and database definitions to use 4-digit year dates.
| 4. Change your COBOL copybooks to reflect these 4-digit year date fields.
| 5. Run a utility program (or special-purpose COBOL program) to copy from the old
| format files to the new format. For a sample program, see Figure 116 on
| page 452.
| 6. Recompile your programs and perform regression testing and date testing.
| After you have completed the first two steps, the remaining steps in the sequence can
| be repeated any number of times. You do not need to change every date field in every
| file at the same time. Using this method, you can select files for progressive conver-
| sion based on criteria such as business needs or interfaces with other applications.
| When you use this method, you will need to write special-purpose programs to convert
| your files to expanded-date form. Figure 116 on page 452 shows a simple program
| that copies from one file to another while expanding the date fields. Note that the
| record length of the output file is larger than that of the input file because the dates are
| expanded.
| CBL LIB,QUOTE,NOOPT,DATEPROC(FLAG),YEARWINDOW(-8ð)
| \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
| \\ CONVERT - Read a file, convert the date \\
| \\ fields to expanded form, write \\
| \\ the expanded records to a new \\
| \\ file. \\
| \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
| IDENTIFICATION DIVISION.
| PROGRAM-ID. CONVERT.
| ENVIRONMENT DIVISION.
| INPUT-OUTPUT SECTION.
| FILE-CONTROL.
| SELECT INPUT-FILE
| ASSIGN TO INFILE
| FILE STATUS IS INPUT-FILE-STATUS.
| SELECT OUTPUT-FILE
| ASSIGN TO OUTFILE
| FILE STATUS IS OUTPUT-FILE-STATUS.
| DATA DIVISION.
| FILE SECTION.
| FD INPUT-FILE
| RECORDING MODE IS F.
| ð1 INPUT-RECORD.
| ð3 CUST-NAME.
| ð5 FIRST-NAME PIC X(1ð).
| ð5 LAST-NAME PIC X(15).
| ð3 ACCOUNT-NUM PIC 9(8).
| ð3 DUE-DATE PIC X(6) DATE FORMAT YYXXXX. .1/
| ð3 REMINDER-DATE PIC X(6) DATE FORMAT YYXXXX.
| ð3 DUE-AMOUNT PIC S9(5)V99 COMP-3.
| FD OUTPUT-FILE
| RECORDING MODE IS F.
| ð1 OUTPUT-RECORD.
| ð3 CUST-NAME.
| ð5 FIRST-NAME PIC X(1ð).
| ð5 LAST-NAME PIC X(15).
| ð3 ACCOUNT-NUM PIC 9(8).
| ð3 DUE-DATE PIC X(8) DATE FORMAT YYYYXXXX. .2/
| ð3 REMINDER-DATE PIC X(8) DATE FORMAT YYYYXXXX.
| ð3 DUE-AMOUNT PIC S9(5)V99 COMP-3.
| WORKING-STORAGE SECTION.
| PROCEDURE DIVISION.
| READ-RECORD.
| READ INPUT-FILE
| AT END GO TO CLOSE-FILES.
| MOVE CORRESPONDING INPUT-RECORD TO OUTPUT-RECORD. .3/
| WRITE OUTPUT-RECORD.
| GO TO READ-RECORD.
| CLOSE-FILES.
| CLOSE INPUT-FILE.
| CLOSE OUTPUT-FILE.
| EXIT PROGRAM.
| Advantages:
| This is a permanent solution; no more changes are required. This solution will
| allow your programs to function into and beyond the year 2000.
| Best performance.
| Maintenance will be easier.
| Disadvantages:
| Need to ensure that changes to databases, copybooks, and programs are all syn-
| chronized.
| Programming Techniques
| This section describes the techniques you can use in your programs to take advantage
| of date processing, and the effects of using date fields on COBOL language elements.
| For full details of COBOL syntax and restrictions, see IBM COBOL Language Refer-
| ence.
| Date Comparisons
| When you compare two date fields, the two dates must be compatible; that is, they
| must have the same number of non-year characters (see “Compatible Dates” on
| page 462). The number of digits for the year component need not be the same. For
| example:
| 77 Todays-Date Pic X(8) Date Format yyyyxxxx.
| ð1 Loan-Record.
| ð5 Date-Due-Back Pic X(6) Date Format yyxxxx.
||| ...
| If Date-Due-Back Greater than Todays-Date Then...
| In this example, a windowed date field is compared to an expanded date field, so the
| century window is applied to Date-Due-Back.
| Note that Todays-Date must have a DATE FORMAT clause in this case to define it as
| an expanded date field. If it did not, it would be treated as a non-date field, and would
| therefore be considered to have the same number of year digits as Date-Due-Back.
| The compiler would apply the assumed century window to it, which would create an
| inconsistent comparison. For more information, see “The Assumed Window” on
| page 464.
| Level 88 Condition-Name
| If a windowed date field has an 88-level condition-name associated with it, the literal in
| the VALUE clause is windowed against the century window for the compilation unit
| rather than the assumed century window of 1900–1999. For example:
| ð5 Date-Due Pic 9(6) Date Format yyxxxx.
| 88 Date-Target Value ð5122ð.
| If the century window is 1950–2049 and the contents of Date-Due is 051220 (repres-
| enting December 20, 2005), then the condition
| If Date-Target
| would evaluate to TRUE, but the condition
| If Date-Due = ð5122ð
| would evaluate to FALSE. This is because the literal 051220 is treated as a non-date,
| and therefore windowed against the assumed century window of 1900–1999 to repre-
| sent December 20, 1905. But where the same literal is specified in the VALUE clause
| of an 88-level condition-name, it becomes part of the data item to which it is attached.
| Because this data item is a windowed date field, the century window is applied when-
| ever it is referenced.
| You can also use the DATEVAL intrinsic function in a comparison expression to convert
| a literal to a date field, and the output from the intrinsic function will then be treated as
| either a windowed or expanded date field to ensure a consistent comparison. For
| example, using the above definitions, both of these conditions
| If Date-Due = Function DATEVAL (ð5122ð "YYXXXX")
| If Date-Due = Function DATEVAL (2ðð5122ð "YYYYXXXX")
| would evaluate to TRUE. For more information on the DATEVAL intrinsic function, see
| “DATEVAL” on page 458.
| Restriction: With a level-88 condition name, you can also specify the THRU option on
| the VALUE clause, for example:
| ð5 Year-Field Pic 99 Date Format yy.
| 88 In-Range Value 98 Thru ð6.
| With this form, the windowed value of the second item must be greater than the win-
| dowed value of the first item. However, the compiler can only verify this if the
| YEARWINDOW compiler option specifies a fixed century window (for example,
| YEARWINDOW(1940) rather than YEARWINDOW(-60)).
| For this reason, if the YEARWINDOW compiler option specifies a sliding century window,
| you cannot use the THRU option on the VALUE clause of a level-88 condition name.
| Arithmetic Expressions
| You can perform arithmetic operations on numeric date fields in the same manner as
| any numeric data item, and, where appropriate, the century window will be used in the
| calculation. However, there are some restrictions on where date fields can be used in
| arithmetic expressions.
| Order of Evaluation
| Because of the restrictions on date fields in arithmetic expressions, you may find that
| programs that previously compiled successfully now produce diagnostic messages
| when some of the data items are changed to date fields.
| However, this is the addition of two date fields, which is not permitted. To resolve this,
| you should use parentheses to isolate those parts of the arithmetic expression that are
| allowed. For example:
| Compute End-Year-2 = Start-Year-2 + (End-Year-1 - Start-Year-1).
| In this case, the first arithmetic expression evaluated is:
| End-Year-1 - Start-Year-1
| This is the subtraction of one date field from another, which is permitted, and gives a
| non-date result. This non-date result is then added to the date field End-Year-1, giving
| a date field result which is stored in End-Year-2.
| If SIZE ERROR is not specified, the result is stored in the receiving field with the
| left-hand digits truncated.
| You can achieve this using a COMPUTE statement to do the contraction, with a SIZE
| ERROR phrase to handle the out-of-window condition. For example:
| Compute Output-Date-YY = Work-Date-YYYY
| On Size Error Go To Out-of-Window-Error-Proc.
| Note: SIZE ERROR processing for windowed date receivers recognizes any year
| value that falls outside the century window. That is, a year value less than the starting
| year of the century window raises the SIZE ERROR condition, as does a year value
| greater than the ending year of the century window.
| If there are date fields in your application that do not fit these criteria, it is not possible
| to define them as date fields with the DATE FORMAT clause. Some examples of
| unsupported date formats are:
| A 3-character field consisting of a 2-digit year and a single character to represent
| the month (A–L representing 1–12). This is not supported because date fields can
| have only zero, 2, 3, or 4 non-year characters.
| A Gregorian date of the form DDMMYY. This is not supported because the year
| component is not the first part of the date.
| If you need to use date windowing in cases like these, you will need to add some code
| to isolate the year portion of the date.
| In the following example, the two date fields contain dates of the form DDMMYY:
| ð3 Last-Review-Date Pic 9(6).
| ð3 Next-Review-Date Pic 9(6).
|| ..
| .
| Add 1 to Last-Review-Date Giving Next-Review-Date.
| In this example, if Last-Review-Date contains 230197 (January 23, 1997), then Next-
| Review-Date will contain 230198 (January 23, 1998) after the ADD statement is exe-
| cuted. This is a simple method of setting the next date for an annual review. However,
| if Last-Review-Date contains 230199, then adding 1 gives 230200, which is not the
| desired result.
| Because the year is not the first part of these date fields, the DATE FORMAT clause
| cannot be applied without some code to isolate the year component. In the next
| example, the year component of both date fields has been isolated so that COBOL can
| apply the century window and maintain consistent results:
| ð3 Last-Review-Date.
| ð5 Last-R-DDMM Pic 9(4).
| ð5 Last-R-YY Pic 99 Date Format yy.
| ð3 Next-Review-Date Pic 9(6).
| ð5 Next-R-DDMM Pic 9(4).
| ð5 Next-R-YY Pic 99 Date Format yy.
|| ..
| .
| Move Last-R-DDMM to Next-R-DDMM.
| Add 1 to Last-R-YY Giving Next-R-YY.
| DATEVAL
| You can use the DATEVAL intrinsic function to convert a non-date into a date field, so
| that COBOL will apply the relevant date processing to the field. The first argument to
| the function is the non-date to be converted, and the second argument specifies the
| date format. The second argument is a literal string with a specification similar to that
| of the date pattern in the DATE FORMAT clause.
| As an example, assume that a program contains a field Date-Copied, and that this field
| is referenced many times in the program, but most of these references simply move it
| between records or reformat it for printing. Only one reference relies on it containing a
| date, for comparison with another date.
| In this case, it is better to leave the field as a non-date, and use the DATEVAL intrinsic
| function in the comparison statement. For example:
| In most cases, the compiler makes the correct assumption about the interpretation of a
| non-date, but accompanies this assumption with a warning-level diagnostic message.
| This typically happens when a windowed date is compared to a literal:
| ð3 When-Made Pic x(6) Date Format yyxxxx.
|| ..
| .
| If When-Made = "85ð7ð1" Perform Warranty-Check.
| The literal is assumed to be a compatible windowed date but with a century window of
| 1900–1999, thus representing July 15, 1985. You can use the DATEVAL intrinsic func-
| tion to make the year of the literal date explicit, and eliminate the warning message:
| If When-Made = Function Dateval("1985ð7ð1" "YYYYXXXX")
| Perform Warranty-Check.
| For a full description and syntax of the DATEVAL intrinsic function, see IBM COBOL
| Language Reference.
| UNDATE
| The UNDATE intrinsic function converts a date field to a non-date, so that it can be
| referenced without any date processing.
| Invoice-Date has been given a DATE FORMAT clause because most of its references
| in the program are date-specific. However, in the instance where it is checked for the
| existence of a control record, the value of "00" in the year component will lead to some
| confusion. A year of "00" in Invoice-Date will represent a “true” year of either 1900 or
| 2000, depending on the century window. This is compared to a non-date (the literal
| "00999" in the example), which will always be windowed against the assumed century
| window and will therefore always represent the year 1900.
| To ensure a consistent comparison, you should use the UNDATE intrinsic function to
| convert Invoice-Date to a non-date. This means that the IF statement is not comparing
| any date fields, so it does not need to apply any windowing. For example:
| ð1 Invoice-Record.
| ð3 Invoice-Date Pic x(5) Date Format yyxxx.
||| ...
| If FUNCTION UNDATE(Invoice-Date) Equal "ðð999" ...
| For a full description and syntax of the UNDATE intrinsic function, see IBM COBOL
| Language Reference.
| You should always eliminate error-level and severe-level messages from your program,
| and it is good programming practice to eliminate warning-level messages as much as
| possible. When the program is compiled and tested satisfactorily, you can then use the
| DATEPROC(NOFLAG) compiler option to produce a listing with as few diagnostic mes-
| sages as possible.
| Principles
| To gain the most benefit from the millennium language extensions, it is important to
| understand the reasons for their introduction into the COBOL language, and the
| rationale behind their design. In particular, there are some apparent inconsistencies
| that only make sense with an understanding of what the extensions are, and what they
| are not.
| You should not consider using the extensions in new applications, or in enhancements
| to existing applications, unless the applications are using old data that cannot be
| expanded until later.
| The extensions do not provide fully-specified or complete date-oriented data types, with
| semantics that recognize, for example, the month and day parts of Gregorian dates.
| They do however provide special semantics for the year part of dates.
| Objectives
| Based on these principles, the millennium language extensions are designed to meet a
| number of objectives. You should evaluate the objectives that you need to meet in
| order to resolve your date processing problems, and compare them against the objec-
| tives of the millennium language extensions, to determine how your application can
| benefit from them.
| Concepts
| With these principles and objectives in mind, you can better understand some of the
| concepts of the millennium language extensions, and how they interact with other parts
| of COBOL. This section describes some of these concepts.
| Date Semantics
| All arithmetic, whether performed on date fields or not, acts only on the numeric con-
| tents of the fields; date semantics for the non-year parts of date fields are not provided.
| For example, adding 1 to a windowed Gregorian date field that contains the value
| 980831 gives a result of 980832, not 980901.
| However, date semantics are provided for the year parts of date fields. For example, if
| the century window is 1950–2049, and the value of windowed date field TwoDigitYear
| is 49, then the following ADD statement will result in the SIZE ERROR imperative state-
| ment being executed:
| Add 1 to TwoDigitYear
| on Size Error Perform CenturyWindowOverflow
| End-Add
| Compatible Dates
| The meaning of the term compatible dates depends on the COBOL division in which
| the usage occurs, as follows:
| The Data Division usage is concerned with the declaration of date fields, and the
| rules governing COBOL language elements such as subordinate data items and
| the REDEFINES clause. In the following example, Review-Date and Review-Year
| are compatible because Review-Year can be declared as a subordinate data item
| to Review-Date:
| ð1 Review-Record.
| ð3 Review-Date Date Format yyxxxx.
| ð5 Review-Year Pic XX Date Format yy.
| ð5 Review-M-D Pic XXXX.
| For full details, see IBM COBOL Language Reference.
| The Procedure Division usage is concerned with how date fields can be used
| together in operations such as comparisons, moves, and arithmetic expressions.
| To be considered compatible, date fields must have the same number of non-year
| characters. For example, a field with DATE FORMAT YYXXXX is compatible with
| another field that has the same DATE FORMAT, and with a YYYYXXXX field, but
| not with a YYXXX field.
| The remainder of this discussion relates to the Procedure Division usage of compatible
| dates.
| You can perform operations on date fields, or on a combination of date fields and non-
| dates, provided that the date fields in the operation are compatible. For example, with
| the following definitions:
| ð1 Date-Gregorian-Win Pic 9(9) Packed Date Format yyxxxx.
| ð1 Date-Julian-Win Pic 9(9) Packed Date Format yyxxx.
| ð1 Date-Gregorian-Exp Pic 9(9) Packed Date Format yyyyxxxx.
| The statement:
| If Date-Gregorian-Win Less than Date-Julian-Win ...
| is inconsistent because the number of non-year digits is different between the two
| fields. The statement:
| If Date-Gregorian-Win Less than Date-Gregorian-Exp ...
| is accepted because the number of non-year digits is the same for both fields. In this
| case the century window is applied to the windowed date field (Date-Gregorian-Win) to
| ensure that the comparison is meaningful.
| Where a non-date is used in conjunction with a date field, the non-date is either
| assumed to be compatible with the date field, or treated as a simple numeric value, as
| described in the following section.
| Treatment of Non-Dates
| The simplest kind of non-date is just a literal value. The following items are also
| non-dates:
| A data item whose data description does not include a DATE FORMAT clause.
| The results (intermediate or final) of some arithmetic expressions. For example,
| the difference of two date fields is a non-date, wheras the sum of a date field and a
| non-date is a date field.
| The output from the UNDATE intrinsic function.
| When you use a non-date in conjunction with a date field, the compiler interprets the
| non-date as either a date whose format is compatible with the date field, or a simple
| numeric value. This interpretation depends on the context in which the date field and
| non-date are used, as follows:
| Comparison
| Where a date field is compared to a non-date, the non-date is considered to be
| compatible with the date field in the number of year and non-year characters. In
| the following example:
| ð1 Date-1 Pic 9(6) Date Format yyxxxx.
||| ...
| If Date-1 Greater than 971231 ...
| Because the non-date literal 971231 is being compared to a windowed date
| field, it is treated as if it had the same DATE FORMAT as Date-1, but with a
| base year of 1900.
| Arithmetic operations
| In all supported arithmetic operations, non-date fields are treated as simple
| numeric values. In the following example:
| ð1 Date-2 Pic 9(6) Date Format yyxxxx.
||| ...
| Add 1ðððð to Date-2.
| the numeric value 10000 is added to the Gregorian date in Date-2, effectively
| adding one year to the date.
| MOVE statement
| Moving a date field to a non-date is not supported. However, you can use the
| UNDATE intrinsic function to achieve this. For more information, see “UNDATE”
| on page 459.
| When you move a non-date to a date field, the sending field is assumed to be
| compatible with the receiving field in the number of year and non-year charac-
| ters. For example, when you move a non-date to a windowed date field, the
| non-date field is assumed to contain a compatible date with a 2-digit year.
| The assumed century window is 1900–1999, which is typically not the same as the
| century window for the compilation unit.
| In many cases, particularly for literal non-dates, this assumed century window will be
| the correct choice. For example, in the construct:
| ð1 manufacturingRecord.
| ð3 makersDate Pic X(6) Date Format yyxxxx.
|| ..
| .
| If makersDate Greater than "72ð1ð1" ...
| the literal should retain its original meaning of January 1, 1972, and not change to 2072
| if the century window is, for example, 1975–2074. Even if the assumption is correct, it
| is better to make the year explicit, and also eliminate the warning-level diagnostic
| message that accompanies application of the assumed century window, by using the
| DATEVAL intrinsic function:
| If makersDate Greater than
| Function Dateval("1972ð1ð1" "YYYYXXXX") ...
| In other cases however, the asumption may not be correct. For example:
| ð1 Project-Controls.
| ð3 Date-Target Pic 9(6).
|| ..
| .
| ð1 Progress-Record.
| ð3 Date-Complete Pic 9(6) Date Format yyxxxx.
||| ...
| If Date-Complete Less than Date-Target ...
| For this example, assume that Project-Controls is in a COPY member that is used by
| other applications that have not yet been upgraded for Year 2000 processing, and
| therefore Date-Target cannot have a DATE FORMAT clause. In the example, if:
| The century window is 1910–2009,
| Date-Complete is 991202 (Gregorian date: December 2, 1999), and
| Date-Target is 000115 (Gregorian date: January 15, 2000),
| then:
| Date-Complete is earlier than (less than) Date-Target.
| However, because Date-Target does not have a DATE FORMAT clause, it is a non-
| date, so the century window applied to it is the assumed century window of 1900–1999,
| which means that it is processed as January 15, 1900. So Date-Complete will be
| greater than Date-Target, which is not the desired result.
| In this case, you should use the DATEVAL intrinsic function to convert Date-Target to a
| date field for this comparison. For example:
| If Date-Complete Less than
| Function Dateval (Date-Target "YYXXXX") ...
| For more information on the DATEVAL intrinsic function, see “DATEVAL” on page 458.
Figure 117 lists the differences between IBM COBOL for OS/390 & VM and IBM
COBOL Set for AIX. For information on COBOL language differences between the dif-
| ferent platforms, see the IBM COBOL Language Reference. For information on devel-
| oping applications that are portable between the different platforms, see Chapter 17,
| “Porting Applications between Platforms” on page 316.
Figure 117 (Page 1 of 3). Product Differences Between Mainframe and Workstation IBM COBOL
Product Function Workstation Implementation
Compiler Options The following compiler options are treated as comments: ADV, AWO,
BUFSIZE, DATA, DECK, DBCS, FASTSRT, FLAGMIG, INTDATE, LAN-
GUAGE, NAME, OUTDD, RENT, and suboptions of TEST. These options
are flagged with I-level messages.
The following compiler options are treated as comments; however, if speci-
fied, the application might yield unpredictable results: NOADV and CMPR2.
These options are flagged with W-level messages.
LIB is the IBM-supplied default on the workstation; NOLIB is the IBM-supplied
default on the host.
Data Representation Binary data types are handled based on the specification of the BINARY
compiler option.
Sign representation for external decimal data are ASCII-based. Specifying
NUMPROC(NOPFD) allows the full range of valid sign values for the
numeric class test.
EBCDIC vs ASCII:
You can specify the EBCDIC collating sequence using the following lan-
guage elements: ALPHABET clause, PROGRAM COLLATING
SEQUENCE clause, and the COLLATING SEQUENCE phrase of the
SORT and MERGE verbs.
You can specify the CHAR(EBCDIC) compiler option to indicate that
DISPLAY data items are in the System/390 data representation
(EBCDIC).
You can use the FLOAT(S390) compiler option to indicate that floating point
data items are in the System/390 data representation (hexadecimal) as
opposed to the native (IEEE) format.
DBCS—Under AIX, OS/2, and Windows, you do not use shift-in or shift-out
delimiters for DBCS literals unless the CHAR(EBCDIC) compiler option is in
effect.
Within an alphanumeric literal, using control characters X'00' through
X'1F' can yield unpredictable results.
Figure 117 (Page 2 of 3). Product Differences Between Mainframe and Workstation IBM COBOL
Product Function Workstation Implementation
Environment Variables IBM COBOL Set for AIX recognizes the following as environment variables:
ASSIGNment name
COBMSGS
COBOPT
COBPATH
COBRTOPT
DB2DBDFT
EBCDIC_CODEPAGE
LANG
LC_COLLATE
LC_MESSAGES
LC_TIME
LIBPATH
library-name specified as a user-defined word
LOCPATH
NLSPATH
SYSIN, SYSIPT, SYSOUT, SYSLIST, SYSLST, CONSOLE,
SYSPUNCH, and SYSPCH
SYSLIB
TEMP
text-name specified as a user-defined word
TZ
File Specification All files are treated as single volume files. All other file specifications are
treated as comments. This affects the following: REEL, UNIT, MULTIPLE
FILE TAPE clause, and CLOSE...UNIT/REEL.
Inter-Language Communication (ILC) ILC is available with C, C++, and PL/I programs.
Figure 117 (Page 3 of 3). Product Differences Between Mainframe and Workstation IBM COBOL
Product Function Workstation Implementation
I-O I-O support for sequential, relative, and indexed files is provided using STL
file system and VSAM. Sizes and values are different for the data-name
returned from the file system.
IBM COBOL Set for AIX does not provide direct support for tape drives or
diskette drives.
Line Sequential I-O is supported using the native byte stream file support of
the platform. The following language elements are treated as comments for
Line Sequential files, as well as for Sequential, Relative, and Indexed files:
ADVANCING phrase of WRITE statement
APPLY WRITE ONLY clause
AT END-OF-PAGE phrase of WRITE statement
BLOCK CONTAINS clause
CODE-SET clause
DATA RECORDS clause
FILE STATUS value 39 (fixed file attribute conflict)
LABEL RECORDS clause
LINAGE clause
OPEN I-O option
PADDING CHARACTER clause
RECORD CONTAINS 0 clause
RECORD CONTAINS clause (format 3)
RECORD DELIMITER clause
RECORDING MODE clause
RERUN clause
RESERVE clause
REVERSED phrase of OPEN statement
VALUE OF clause of file description entry
Run-Time Options The following run-time options are not recognized by IBM COBOL Set for
AIX and will be treated as invalid options: AIXBLD, ALL31, CBLPSHPOP,
CBLQDA, COUNTRY, HEAP, MSGFILE, NATLANG, SIMVRD, and STACK.
| On the host, the STORAGE run-time option can be used to initialize COBOL
| working storage. With IBM COBOL Set for AIX, this is achieved with the
| WSCLEAR compiler option.
Source Code Line A COBOL source line can be less than 72 characters. A line ends on
column 72 or where a carriage control character is found.
CICS Access
CICS allows you to specify various data conversion choices at various places and at
various granularities. For example, client CICS translator option specifications on the
server for different resources (file, EIBLK, COMMAREA, transient data queue, etc.).
Your use of host versus native data depends on such selections. Refer to the appro-
priate CICS documentation for specific information about how such choices can best be
made.
| Note: System/390 host data type support is only allowed on the following CICS
| systems using the EBCDIC enablement support:
| CICS for OS/2
| VisualAge CICS Enterprise Application Development
It will not work for COBOL programs that are translated by the CICS translator and run
on CICS for Windows NT or CICS for AIX.
To avoid this problem, you must be aware of the maximum floating point values sup-
ported on either platform for the respective data types. The limits are shown in
Figure 118
As shown above, the System/390 host can carry a larger COMP-1 value than the work-
station and the workstation can carry a larger COMP-2 value than the System/390 host.
DB2
| The System/390 host data type compiler options can be used with DB2 programs.
MQSeries
The System/390 host data type compiler options should not be used with MQSeries
programs.
SORT
| All of the System/390 host data types can be used as sort keys.
For a discussion on when the compiler uses fixed-point or floating-point arithmetic, refer
to “Fixed-Point versus Floating-Point Arithmetic” on page 43.
In the following discussion of how the compiler determines the number of integer and
decimal places reserved for intermediate results, these abbreviations are used:
i The number of integer places carried for an intermediate result.
d The number of decimal places carried for an intermediate result.
ROUNDED
If the ROUNDED option is used, one more integer or decimal might be added
for accuracy, if necessary. Only the final results are rounded; the interme-
diate results are not rounded.
dmax In a particular statement, the largest of:
The number of decimal places needed for the final result field(s).
The maximum number of decimal places defined for any operand,
except divisors or exponents.
The outer-dmax for any function operand.
inner-dmax
The inner-dmax for a function is the largest of:
The number of decimal places defined for any of its elementary argu-
ments.
The dmax for any of its arithmetic expression arguments.
The outer-dmax for any of its embedded functions.
outer-dmax
The number that determines how a function result contributes to operations
outside of its own evaluation (for example, if the function is an operand in an
arithmetic expression or an argument to another function).
op1 The first operand in a generated arithmetic statement. For division, op1 is
the divisor.
op2 The second operand in a generated arithmetic statement. For division, op2
is the dividend.
i1,i2 The number of integer places in op1 and op2, respectively.
d1,d2 The number of decimal places defined for op1 and op2, respectively.
ir The intermediate result field obtained when a generated arithmetic statement
or operation is performed. ir1, ir2,. . ., represent successive intermediate
results. These intermediate results are generated either in registers or in
storage locations. Successive intermediate results might have the same
location.
The compiler handles each statement as a succession of operations. For example, the
following statement:
COMPUTE Y = A + B \ C - D / E + F \\ G
is calculated as:
** F BY G yielding ir1
MULTIPLY B BY C yielding ir2
DIVIDE E INTO D yielding ir3
ADD A TO ir2 yielding ir4
SUBTRACT ir3 FROM ir4 yielding ir5
ADD ir5 TO ir1 yielding Y
You must define the operands of any arithmetic statements with enough decimal places
to give the desired accuracy in the final result.
Figure 120 indicates the action of the compiler when handling intermediate results for
fixed-point numbers.
Figure 120. Determining When the Compiler Might Truncate Intermediate Results
Value of Value of Value of Action Taken
i + d d i + dmax
<30 Any value Any value i integer and d decimal places are carried for ir.
=30
>30 <dmax Any value 30-d integer and d decimal places are carried for ir.
=dmax
>dmax <30 i integer and 30-i decimal places are carried for ir.
=30
>30 30-dmax integer and dmax decimal places are carried
for ir.
Having calculated i and d, the compiler takes the action indicated in the following
figure to handle intermediate results:
Figure 121. Determining When the Compiler Might Truncate Intermediate Results for
Exponentiation
Value of Other Conditions Action Taken
i + d
<30 Any i integer and d decimal places are carried for ir.
=30 op1 has an odd i integer and d decimal places are carried for ir.
number of digits
op1 has an even The exponentiation is handled the same as it is when
number of digits op2 is an integral data-name or a variable, except in
the case of a 30-digit integer raised to the power of
literal 1, where the computation is done following the
rules for op1 with an odd number of digits.
>30 Any The exponentiation is handled the same as it is when
op2 is an integral data-name or a variable.
If op2 is negative, the value of 1 is divided by the result produced by the prelimi-
nary computation described above. The values of i and d that are used are calcu-
lated using the rules for division found in Figure 119 on page 473.
When op2 is an integral data-name or a variable, dmax decimals and 3ð-dmax inte-
gers are used. Here, op1 is multiplied by itself (|op2| - 1) times. For example,
the following statement:
COMPUTE Y = A \\ B, where B has a value of 4
is calculated as:
The values of i and d that are used for the above multiplications are calculated
using the rules for multiplication found in Figure 119 on page 473.
If B is positive, Y = ir4.
If B is negative, however,
DIVIDE ir4 INTO 1 yielding ir5, which has dmax decimals
Y = ir5
If op2 is equal to zero, the answer is 1. Division-by-0 and exponentiation SIZE
ERROR conditions apply. For specific information on the SIZE ERROR option, see
the IBM COBOL Language Reference.
Fixed-point exponents with more than 9 significant digits are always truncated to 9
digits. If the exponent is a literal or constant, an E-level compiler diagnostic message is
issued; otherwise, an informational message is issued at run time.
If you think an intermediate result field might exceed 30 digits, you can use floating-
point operands (COMP-1 and COMP-2) to avoid truncation.
Binary items are used most efficiently when the intermediate result is not greater than 9
digits.
Integer Functions
These functions always return an integer, and the outer-dmax will always be zero. For
those functions whose arguments must be integer, the inner-dmax will also always be
zero.
Mixed Functions
When the compiler handles a mixed function as fixed-point arithmetic, the result will be
either integer or fixed-point with decimals (when any argument is floating-point, the
function becomes a floating-point function and will follow floating-point rules). For MAX,
MIN, RANGE, REM, and SUM, the outer-dmax is always equal to the inner-dmax. To
determine the precision of the result returned for these functions, apply the rules for
fixed-point arithmetic to each step in the algorithm used to calculate the function result.
MAX
MIN
RANGE
REM
SUM
The value of a negative number raised to a fractional power is undefined. For example,
(-2) ** 3 is equal to -8, but (-2) ** (3.000001) is not defined. When an exponentiation is
evaluated in floating-point and there is a possibility that the value of the exponentiation
will be undefined (as in the example above), then the value of the exponent is evalu-
ated at run time to determine if it is actually an integer.
Mixed functions with floating-point arguments will be evaluated using floating-point arith-
metic.
The length of the variable portions of each record is the product of the ODO object and
the length of the subject of the OCCURS clause. The length is calculated at the time of
a reference to one of the following:
A data item following, and not subordinate to, a variable-length table in the same
level-01 record (variably-located item).
.1/ in the following example.
A group item following, and not subordinate to, a variable-length table in the same
level-01 record (variably-located group).
.2/ in the following example.
An index name for a table that has variable-length elements.
.3/ in the following example.
An element of a table that has variable-length elements.
.4/ in the following example.
the variable item to a work area; after the change in the ODO object, move all the
items back.
For example:
77 INTEGER-DATA-ITEM-1 PIC 99.
SET INDX TO 5
\ INDX is valid at this point.
SET INTEGER-DATA-ITEM-1 TO INDX
MOVE NEW-VALUE TO COUNTER-2.
\ INDX is not valid at this point.
SET INDX TO INTEGER-DATA-ITEM-1.
\ INDX Is now valid and can be
\ used with expected results.
WORKING-STORAGE SECTION.
ð1 VARIABLE-REC.
ð5 FIELD-1 PIC X(1ð).
ð5 CONTROL-1 PIC S99.
ð5 CONTROL-2 PIC S99.
ð5 VARY-FIELD-1 OCCURS 1 TO 1ð TIMES
DEPENDING ON CONTROL-1 PIC X(5).
ð5 GROUP-ITEM-1.
1ð VARY-FIELD-2
OCCURS 1 TO 1ð TIMES
DEPENDING ON CONTROL-2 PIC X(9).
ð1 STORE-VARY-FIELD-2.
ð5 GROUP-ITEM-2.
1ð VARY-FLD-2
OCCURS 1 TO 1ð TIMES
DEPENDING ON CONTROL-2 PIC X(9).
Assume that both CONTROL-1 and CONTROL-2 contain the value 3. In this situation,
storage for VARY-FIELD-1 and VARY-FIELD-2 would look like this:
┌──┬──┬──┬──┬──┐
VARY─FIELD─1(1) │ │ │ │ │ │
├──┼──┼──┼──┼──┤
VARY─FIELD─1(2) │ │ │ │ │ │
├──┼──┼──┼──┼──┤
VARY─FIELD─1(3) │ │ │ │ │ │
├──┼──┼──┼──┼──┼──┬──┬──┬──┐
VARY─FIELD─2(1) │ │ │ │ │ │ │ │ │ │
├──┼──┼──┼──┼──┼──┼──┼──┼──┤
VARY─FIELD─2(2) │ │ │ │ │ │ │ │ │ │
├──┼──┼──┼──┼──┼──┼──┼──┼──┤
VARY─FIELD─2(3) │ │ │ │ │ │ │ │ │ │
└──┴──┴──┴──┴──┴──┴──┴──┴──┘
In order to add a fourth field to VARY-FIELD-1, the following steps are required to
prevent VARY-FIELD-1 from overlaying the first 5 bytes of VARY-FIELD-2:
MOVE GROUP-ITEM-1 TO GROUP-ITEM-2
ADD 1 TO CONTROL-1
MOVE "additional field" TO
VARY-FIELD-1 (CONTROL-1)
MOVE GROUP-ITEM-2 TO GROUP-ITEM-1
The updated storage for VARY-FIELD-1 and VARY-FIELD-2 would now look like this:
┌──┬──┬──┬──┬──┐
VARY─FIELD─1(1) │ │ │ │ │ │
├──┼──┼──┼──┼──┤
VARY─FIELD─1(2) │ │ │ │ │ │
├──┼──┼──┼──┼──┤
VARY─FIELD─1(3) │ │ │ │ │ │
├──┼──┼──┼──┼──┤
VARY─FIELD─1(4) │ │ │ │ │ │
├──┼──┼──┼──┼──┼──┬──┬──┬──┐
VARY─FIELD─2(1) │ │ │ │ │ │ │ │ │ │
├──┼──┼──┼──┼──┼──┼──┼──┼──┤
VARY─FIELD─2(2) │ │ │ │ │ │ │ │ │ │
├──┼──┼──┼──┼──┼──┼──┼──┼──┤
VARY─FIELD─2(3) │ │ │ │ │ │ │ │ │ │
└──┴──┴──┴──┴──┴──┴──┴──┴──┘
The intent of this last example is to emphasize that if you want to preserve the values
contained in data items that follow a variable-length item within the same record, you
must move them to another field prior to changing the length of the variable-length item,
and then move them back after the length indicator has been changed.
Syntax
55──CALL──"CEECBLDY"──USING──input_char_date──,──picture_string──,─────5
5──output_Integer_date──,──fc──.──────────────────────────────────────5%
input_char_date (input)
A halfword length-prefixed character string, representing a date or timestamp, in a
format conforming to that specified by picture_string.
The character string must contain between 5 and 255 characters, inclusive.
input_char_date can contain leading or trailing blanks. Parsing for a date begins
with the first nonblank character (unless the picture string itself contains leading
blanks, in which case CEECBLDY skips exactly that many positions before parsing
begins).
After parsing a valid date, as determined by the format of the date specified in
picture_string, CEECBLDY ignores all remaining characters. Valid dates range
between and include 01 January 1601 to 31 December 9999.
See Figure 110 on page 426 for a list of valid picture character terms that can be
specified in input_char_date.
picture_string (input)
A halfword length-prefixed character string, indicating the format of the date speci-
fied in input_char_date.
Each character in the picture_string corresponds to a character in input_char_date.
For example, if you specify MMDDYY as the picture_string, CEECBLDY reads an
input_char_date of 060288 as 02 June 1988.
If delimiters such as the slash (/) appear in the picture string, leading zeros can be
omitted. For example, the following calls to CEECBLDY:
MOVE '6/2/88' TO DATEVAL-STRING.
MOVE 6 TO DATEVAL-LENGTH.
MOVE 'MM/DD/YY' TO PICSTR-STRING.
MOVE 8 TO PICSTR-LENGTH.
CALL CEECBLDY USING DATEVAL, PICSTR, COBINTDTE, FC.
output_Integer_date (output)
A 32-bit binary integer representing the COBOL Integer date, the number of days
since 31 December 1600. For example, 16 May 1988 is day number 141485.
If input_char_date does not contain a valid date, output_Integer_date is set to 0
and CEECBLDY terminates with a non-CEE000 symbolic feedback code.
Date calculations are performed easily on the output_Integer_date, because
output_Integer_date is an integer. Leap year and end-of-year anomalies do not
affect the calculations.
fc (output)
A 12-byte feedback code (optional), that indicates the result of this service.
The following symbolic conditions can result from this service:
Symbolic
Feedback Message
Code Severity Number Message Text
CEE000 0 — The service completed successfully.
CEE2EB 3 2507 Insufficient data was passed to CEEDAYS
or CEESECS. The Lilian value was not cal-
culated.
CEE2EC 3 2508 The date value passed to CEEDAYS or
CEESECS was invalid.
CEE2ED 3 2509 The Japanese or Republic of China Era
passed to CEEDAYS or CEESECS was not
recognized.
CEE2EH 3 2513 The input date passed in a CEEISEC,
CEEDAYS, or CEESECS call was not within
the supported range.
CEE2EL 3 2517 The month value in a CEEISEC call was not
recognized.
CEE2EM 3 2518 An invalid picture string was specified in a
call to a date/time service.
CEE2EO 3 2520 CEEDAYS detected non-numeric data in a
numeric field, or the date string did not
match the picture string.
CEE2EP 3 2521 The Japanese (<JJJJ>) or Chinese
(<CCCC>) year-within-Era value passed to
CEEDAYS or CEESECS was zero.
Usage Notes
Call CEECBLDY only from COBOL programs that use the returned value as input
to COBOL intrinsic functions. You should not use the returned value with other
date and time callable services, nor should you call CEECBLDY from any
non-COBOL programs. Unlike CEEDAYS, there is no inverse function of
CEECBLDY, because it is only for COBOL users who want to use the date and
time century window service together with COBOL intrinsic functions for date calcu-
lations. The inverse function of CEECBLDY is provided by the
DATE-OF-INTEGER and DAY-OF-INTEGER intrinsic functions.
To perform calculations on dates earlier than 1 January 1601, add 4000 to the year
in each date, convert the dates to COBOL Integer format, then do the calculation.
If the result of the calculation is a date, as opposed to a number of days, convert
the result to a date string and subtract 4000 from the year.
By default, 2-digit years lie within the 100-year range starting 80 years prior to the
system date. Thus, in 1997, all 2-digit years represent dates between 1917 and
2016, inclusive. You can change this default range by using the CEESCEN call-
able service.
Example
CBL LIB,APOST
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
\\ \\
\\ Function: Invoke CEECBLDY callable service \\
\\ to convert date to COBOL Integer format. \\
\\ This service is used when using the \\
\\ Century Window feature of the date and time \\
\\ callable services mixed with COBOL \\
\\ Intrinsic Functions. \\
\\ \\
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
IDENTIFICATION DIVISION.
PROGRAM-ID. CBLDY.
DATA DIVISION.
WORKING-STORAGE SECTION.
ð1 CHRDATE.
ð2 Vstring-length PIC S9(4) BINARY.
ð2 Vstring-text.
ð3 Vstring-char PIC X
OCCURS ð TO 256 TIMES
DEPENDING ON Vstring-length
of CHRDATE.
ð1 PICSTR.
ð2 Vstring-length PIC S9(4) BINARY.
ð2 Vstring-text.
ð3 Vstring-char PIC X
OCCURS ð TO 256 TIMES
DEPENDING ON Vstring-length
of PICSTR.
ð1 INTEGER PIC S9(9) BINARY.
ð1 NEWDATE PIC 9(8).
ð1 FC.
ð2 Condition-Token-Value.
COPY CEEIGZCT.
ð3 Case-1-Condition-ID.
ð4 Severity PIC S9(4) COMP.
ð4 Msg-No PIC S9(4) COMP.
ð3 Case-2-Condition-ID
REDEFINES Case-1-Condition-ID.
ð4 Class-Code PIC S9(4) COMP.
ð4 Cause-Code PIC S9(4) COMP.
ð3 Case-Sev-Ctl PIC X.
ð3 Facility-ID PIC XXX.
ð2 I-S-Info PIC S9(9) COMP.
PROCEDURE DIVISION.
PARA-CBLDAYS.
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
\\ Specify input date and length \\
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
MOVE 25 TO Vstring-length of CHRDATE.
MOVE '1 January ðð'
to Vstring-text of CHRDATE.
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
\\ Specify a picture string that describes \\
\\ input date, and set the string's length. \\
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
MOVE 23 TO Vstring-length of PICSTR.
MOVE 'ZD Mmmmmmmmmmmmmmz YY'
TO Vstring-text of PICSTR.
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
\\ Call CEECBLDY to convert input date to a \\
\\ COBOL Integer date \\
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
CALL 'CEECBLDY' USING CHRDATE, PICSTR,
INTEGER, FC.
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
\\ If CEECBLDY runs successfully, then compute \\
\\ the date of the 9ðth day after the \\
\\ input date using Intrinsic Functions \\
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
IF CEEððð of FC THEN
COMPUTE INTEGER = INTEGER + 9ð
COMPUTE NEWDATE = FUNCTION
DATE-OF-INTEGER (INTEGER)
DISPLAY NEWDATE
' is Lilian day: ' INTEGER
ELSE
DISPLAY 'CEEBLDY failed with msg '
Msg-No of FC UPON CONSOLE
STOP RUN
END-IF.
GOBACK.
Syntax
55──CALL──"CEEDATE"──USING──input_Lilian_date──,──picture_string──,────5
5──output_char_date──,──fc──.─────────────────────────────────────────5%
input_Lilian_date (input)
A 32-bit integer representing the Lilian date. The Lilian date is the number of days
since 14 October 1582. For example, 16 May 1988 is Lilian day number 148138.
The valid range of Lilian dates is 1 to 3,074,324 (15 October 1582 to 31 December
9999).
picture_string (input)
A halfword length-prefixed character string, representing the desired format of
output_char_date, for example MM/DD/YY. Each character in picture_string repres-
ents a character in output_char_date. If delimiters such as the slash (/) appear in
the picture string, they are copied as is to output_char_date.
See Figure 110 on page 426 for a list of valid picture characters, and Figure 111
on page 427 for examples of valid picture strings.
If picture_string includes a Japanese Era symbol <JJJJ>, the YY position in
output_char_date is replaced by the year number within the Japanese Era. For
example, the year 1988 equals the Japanese year 63 in the Showa era. See
Figure 111 on page 427 for an additional example. See Figure 112 on page 428
for a list of Japanese Eras supported.
If picture_string includes an ROC (Republic of China) Era symbol <CCCC> or
<CCCCCCCC>, the YY position in output_char_date is replaced by the year number
within the ROC Era. For example, the year 1988 equals the ROC year 77 in the
MinKow Era. See Figure 111 on page 427 for an additional example. See
Figure 113 on page 428 for a list of ROC Eras supported.
output_char_date (output)
A fixed-length 80-character string that is the result of converting input_Lilian_date
to the format specified by picture_string. See Figure 123 on page 492 for sample
output dates. If input_Lilian_date is invalid, output_char_date is set to all blanks
and CEEDATE terminates with a non-CEE000 symbolic feedback code.
fc (output)
A 12-byte feedback code (optional), that indicates the result of this service.
The following symbolic conditions can result from this service:
Symbolic
Feedback Message
Code Severity Number Message Text
CEE000 0 — The service completed successfully.
CEE2EG 3 2512 The Lilian date value passed in a call to
CEEDATE or CEEDYWK was not within the
supported range.
Symbolic
Feedback Message
Code Severity Number Message Text
CEE2EM 3 2518 An invalid picture string was specified in a
call to a date/time service.
CEE2EQ 3 2522 Japanese (<JJJJ>) or Republic of China
(<CCCC> or <CCCCCCCC>) Era was used
in a picture string passed to CEEDATE, but
the Lilian date value was not within the sup-
ported range. The era could not be deter-
mined.
CEE2EU 2 2526 The date string returned by CEEDATE was
truncated.
CEE2F6 1 2534 Insufficient field width was specified for a
month or weekday name in a call to
CEEDATE or CEEDATM. Output set to
blanks.
Usage Notes
The inverse of CEEDATE is CEEDAYS, which converts character dates to the
Lilian format.
Example
CBL LIB,APOST
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
\\ \\
\\ Function: CEEDATE - convert Lilian date to \\
\\ character format \\
\\ \\
\\ In this example, a call is made to CEEDATE \\
\\ to convert a Lilian date (the number of \\
\\ days since 14 October 1582) to a character \\
\\ format (such as 6/22/88). The result is \\
\\ displayed. The Lilian date is obtained \\
\\ via a call to CEEDAYS. \\
\\ \\
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
IDENTIFICATION DIVISION.
PROGRAM-ID. CBLDATE.
DATA DIVISION.
WORKING-STORAGE SECTION.
ð1 LILIAN PIC S9(9) BINARY.
PROCEDURE DIVISION.
PARA-CBLDAYS.
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
\\ Call CEEDAYS to convert date of 6/2/88 to \\
\\ Lilian representation \\
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
MOVE 6 TO Vstring-length of IN-DATE.
MOVE '6/2/88' TO Vstring-text of IN-DATE(1:6).
MOVE 8 TO Vstring-length of PICSTR.
MOVE 'MM/DD/YY' TO Vstring-text of PICSTR(1:8).
CALL 'CEEDAYS' USING IN-DATE, PICSTR,
LILIAN, FC.
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
\\ If CEEDAYS runs successfully, display result\\
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
IF CEEððð of FC THEN
DISPLAY Vstring-text of IN-DATE
' is Lilian day: ' LILIAN
ELSE
DISPLAY 'CEEDAYS failed with msg '
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
\\ Specify picture string that describes the \\
\\ desired format of the output from CEEDATE, \\
\\ and the picture string's length. \\
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
MOVE 23 TO Vstring-length OF PICSTR.
MOVE 'ZD Mmmmmmmmmmmmmmz YYYY' TO
Vstring-text OF PICSTR(1:23).
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
\\ Call CEEDATE to convert the Lilian date \\
\\ to a picture string. \\
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
CALL 'CEEDATE' USING LILIAN, PICSTR,
CHRDATE, FC.
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
\\ If CEEDATE runs successfully, display result\\
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
IF CEEððð of FC THEN
DISPLAY 'Input Lilian date of ' LILIAN
' corresponds to: ' CHRDATE
ELSE
DISPLAY 'CEEDATE failed with msg '
Msg-No of FC UPON CONSOLE
STOP RUN
END-IF.
GOBACK.
Wwwwwwwwww, Saturday ,
Mmmmmmmmmm DD, YYYY May 21, 1988
Syntax
55──CALL──"CEEDATM"──USING──input_seconds──,──picture_string──,────────5
5──output_timestamp──,──fc──.─────────────────────────────────────────5%
input_seconds (input)
A 64-bit double floating-point number representing the number of seconds since
00:00:00 on 14 October 1582, not counting leap seconds.
For example, 00:00:01 on 15 October 1582 is second number 86,401 (24*60*60 +
01). The valid range of input_seconds is 86,400 to 265,621,679,999.999
(23:59:59.999 31 December 9999).
picture_string (input)
A halfword length-prefixed character string, representing the desired format of
output_timestamp, for example, MM/DD/YY HH:MI AP.
Each character in the picture_string represents a character in output_timestamp. If
delimiters such as a slash (/) appear in the picture string, they are copied as is to
output_timestamp.
See Figure 110 on page 426 for a list of valid picture character terms and
Figure 111 on page 427 for examples of valid picture strings.
If picture_string includes the Japanese Era symbol <JJJJ>, the YY position in
output_timestamp represents the year within Japanese Era. See Figure 111 on
page 427 for an example. See Figure 112 on page 428 for a list of Japanese
Eras supported.
If picture_string includes the ROC (Republic of China) Era symbol <CCCC> or
<CCCCCCCC>, the YY position in output_timestamp represents the year within ROC
Era. See Figure 111 on page 427 for an example. See Figure 113 on page 428
for a list of ROC Eras supported.
output_timestamp (output)
A fixed-length 80-character string that is the result of converting input_seconds to
the format specified by picture_string.
If necessary, the output is truncated to the length of output_timestamp. See
Figure 124 on page 497 for sample output.
If input_seconds is invalid, output_timestamp is set to all blanks and CEEDATM
terminates with a non-CEE000 symbolic feedback code.
fc (output)
A 12-byte feedback code (optional), that indicates the result of this service.
The following symbolic conditions can result from this service:
Symbolic
Feedback Message
Code Severity Number Message Text
CEE000 0 — The service completed successfully.
CEE2E9 3 2505 The input_seconds value in a call to
CEEDATM or CEESECI was not within the
supported range.
CEE2EA 3 2506 Japanese (<JJJJ>) or Republic of China
(<CCCC> or <CCCCCCCC>) Era was used
in a picture string passed to CEEDATM, but
the input number-of-seconds value was not
within the supported range. The era could
not be determined.
CEE2EM 3 2518 An invalid picture string was specified in a
call to a date/time service.
CEE2EV 2 2527 The timestamp string returned by
CEEDATM was truncated.
Symbolic
Feedback Message
Code Severity Number Message Text
CEE2F6 1 2534 Insufficient field width was specified for a
month or weekday name in a call to
CEEDATE or CEEDATM. Output set to
blanks.
Usage Notes
The inverse of CEEDATM is CEESECS, which converts a timestamp to number of
seconds.
Example
CBL LIB,APOST
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
\\ \\
\\ Function: CEEDATM - convert seconds to \\
\\ character timestamp \\
\\ \\
\\ In this example, a call is made to CEEDATM \\
\\ to convert a date represented in Lilian \\
\\ seconds (the number of seconds since \\
\\ ðð:ðð:ðð 14 October 1582) to a character \\
\\ format (such as ð6/ð2/88 1ð:23:45). The \\
\\ result is displayed. \\
\\ \\
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
IDENTIFICATION DIVISION.
PROGRAM-ID. CBLDATM.
DATA DIVISION.
WORKING-STORAGE SECTION.
ð1 DEST PIC S9(9) BINARY VALUE 2.
ð1 SECONDS COMP-2.
ð1 IN-DATE.
ð2 Vstring-length PIC S9(4) BINARY.
ð2 Vstring-text.
ð3 Vstring-char PIC X
OCCURS ð TO 256 TIMES
DEPENDING ON Vstring-length
of IN-DATE.
ð1 PICSTR.
ð2 Vstring-length PIC S9(4) BINARY.
ð2 Vstring-text.
ð3 Vstring-char PIC X
OCCURS ð TO 256 TIMES
DEPENDING ON Vstring-length
of PICSTR.
ð1 TIMESTP PIC X(8ð).
ð1 FC.
ð2 Condition-Token-Value.
COPY CEEIGZCT.
ð3 Case-1-Condition-ID.
ð4 Severity PIC S9(4) COMP.
ð4 Msg-No PIC S9(4) COMP.
ð3 Case-2-Condition-ID
REDEFINES Case-1-Condition-ID.
ð4 Class-Code PIC S9(4) COMP.
ð4 Cause-Code PIC S9(4) COMP.
ð3 Case-Sev-Ctl PIC X.
ð3 Facility-ID PIC XXX.
ð2 I-S-Info PIC S9(9) COMP.
PROCEDURE DIVISION.
PARA-CBLDATM.
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
\\ Call CEESECS to convert timestamp of 6/2/88 \\
\\ at 1ð:23:45 AM to Lilian representation \\
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
MOVE 2ð TO Vstring-length of IN-DATE.
MOVE 'ð6/ð2/88 1ð:23:45 AM'
TO Vstring-text of IN-DATE.
MOVE 2ð TO Vstring-length of PICSTR.
MOVE 'MM/DD/YY HH:MI:SS AP'
TO Vstring-text of PICSTR.
CALL 'CEESECS' USING IN-DATE, PICSTR,
SECONDS, FC.
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
\\ If CEESECS runs successfully, display result\\
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
IF CEEððð of FC THEN
DISPLAY Vstring-text of IN-DATE
' is Lilian second: ' SECONDS
ELSE
DISPLAY 'CEESECS failed with msg '
Msg-No of FC UPON CONSOLE
STOP RUN
END-IF.
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
\\ Specify desired format of the output. \\
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
MOVE 35 TO Vstring-length OF PICSTR.
MOVE 'ZD Mmmmmmmmmmmmmmz YYYY at HH:MI:SS'
TO Vstring-text OF PICSTR.
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
\\ Call CEEDATM to convert Lilian seconds to \\
\\ a character timestamp \\
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
CALL 'CEEDATM' USING SECONDS, PICSTR,
TIMESTP, FC.
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
\\ If CEEDATM runs successfully, display result\\
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
IF CEEððð of FC THEN
DISPLAY 'Input seconds of ' SECONDS
' corresponds to: ' TIMESTP
ELSE
DISPLAY 'CEEDATM failed with msg '
Msg-No of FC UPON CONSOLE
STOP RUN
END-IF.
GOBACK.
Do not use CEEDAYS in combination with COBOL intrinsic functions. Use CEECBLDY
for programs that use intrinsic functions.
Syntax
55──CALL──"CEEDAYS"──USING──input_char_date──,──picture_string──,──────5
5──output_Lilian_date──,──fc──.───────────────────────────────────────5%
input_char_date (input)
A halfword length-prefixed character string, representing a date or timestamp, in a
format conforming to that specified by picture_string.
The character string must contain between 5 and 255 characters, inclusive.
input_char_date can contain leading or trailing blanks. Parsing for a date begins
with the first nonblank character (unless the picture string itself contains leading
blanks, in which case CEEDAYS skips exactly that many positions before parsing
begins).
After parsing a valid date, as determined by the format of the date specified in
picture_string, CEEDAYS ignores all remaining characters. Valid dates range
between and include 15 October 1582 to 31 December 9999.
See Figure 110 on page 426 for a list of valid picture character terms that can be
specified in input_char_date.
picture_string (input)
A halfword length-prefixed character string, indicating the format of the date speci-
fied in input_char_date.
Each character in the picture_string corresponds to a character in input_char_date.
For example, if you specify MMDDYY as the picture_string, CEEDAYS reads an
input_char_date of 060288 as 02 June 1988.
If delimiters such as a slash (/) appear in the picture string, leading zeros can be
omitted. For example, the following calls to CEEDAYS:
CALL CEEDAYS USING '6/2/88' , 'MM/DD/YY', lildate, fc.
CALL CEEDAYS USING 'ð6/ð2/88', 'MM/DD/YY', lildate, fc.
CALL CEEDAYS USING 'ð6ð288' , 'MMDDYY' , lildate, fc.
CALL CEEDAYS USING '88154' , 'YYDDD' , lildate, fc.
would each assign the same value, 148155 (02 June 1988), to lildate.
Whenever characters such as colons or slashes are included in the picture_string
(such as HH:MI:SS YY/MM/DD), they count as placeholders but are otherwise
ignored.
See Figure 110 on page 426 for a list of valid picture character terms, and
Figure 111 on page 427 for examples of valid picture strings.
If picture_string includes a Japanese Era symbol <JJJJ>, the YY position in
input_char_date is replaced by the year number within the Japanese Era. For
example, the year 1988 equals the Japanese year 63 in the Showa era. See
Figure 111 on page 427 for an additional example. See Figure 112 on page 428
for a list of Japanese Eras supported.
If picture_string includes an ROC (Republic of China) Era symbol <CCCC> or
<CCCCCCCC>, the YY position in input_char_date is replaced by the year number
within the ROC Era. For example, the year 1988 equals the ROC year 77 in the
MinKow Era. See Figure 111 on page 427 for an additional example. See
Figure 113 on page 428 for a list of ROC Eras supported.
output_Lilian_date (output)
A 32-bit binary integer representing the Lilian date, the number of days since 14
October 1582. For example, 16 May 1988 is day number 148138.
If input_char_date does not contain a valid date, output_Lilian_date is set to 0 and
CEEDAYS terminates with a non-CEE000 symbolic feedback code.
Date calculations are performed easily on the output_Lilian_date, because it is an
integer. Leap year and end-of-year anomalies do not affect the calculations.
fc (output)
A 12-byte feedback code (optional), that indicates the result of this service.
The following symbolic conditions can result from this service:
Symbolic
Feedback Message
Code Severity Number Message Text
CEE000 0 — The service completed successfully.
CEE2EB 3 2507 Insufficient data was passed to CEEDAYS
or CEESECS. The Lilian value was not cal-
culated.
CEE2EC 3 2508 The date value passed to CEEDAYS or
CEESECS was invalid.
CEE2ED 3 2509 The Japanese or Republic of China Era
passed to CEEDAYS or CEESECS was not
recognized.
CEE2EH 3 2513 The input date passed in a CEEISEC,
CEEDAYS, or CEESECS call was not within
the supported range.
CEE2EL 3 2517 The month value in a CEEISEC call was not
recognized.
CEE2EM 3 2518 An invalid picture string was specified in a
call to a date/time service.
CEE2EO 3 2520 CEEDAYS detected non-numeric data in a
numeric field, or the date string did not
match the picture string.
CEE2EP 3 2521 The Japanese (<JJJJ>) or Chinese
(<CCCC>) year-within-Era value passed to
CEEDAYS or CEESECS was zero.
Usage Notes
The inverse of CEEDAYS is CEEDATE, which converts output_Lilian_date from
Lilian format to character format.
To perform calculations on dates earlier than 15 October 1582, add 4000 to the
year in each date, convert the dates to Lilian, then do the calculation. If the result
of the calculation is a date, as opposed to a number of days, convert the result to a
date string and subtract 4000 from the year.
By default, 2-digit years lie within the 100-year range starting 80 years prior to the
system date. Thus, in 1997, all 2-digit years represent dates between 1917 and
2016, inclusive. This default range is changed by using the callable service
CEESCEN.
Date calculations can be performed easily on the output_Lilian_date, because it is
an integer. Leap year and end-of-year anomalies are avoided.
Example
CBL LIB,APOST
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
\\ \\
\\ Function: CEEDAYS - convert date to \\
\\ Lilian format \\
\\ \\
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
IDENTIFICATION DIVISION.
PROGRAM-ID. CBLDAYS.
DATA DIVISION.
WORKING-STORAGE SECTION.
ð1 CHRDATE.
ð2 Vstring-length PIC S9(4) BINARY.
ð2 Vstring-text.
ð3 Vstring-char PIC X
OCCURS ð TO 256 TIMES
DEPENDING ON Vstring-length
of CHRDATE.
ð1 PICSTR.
ð2 Vstring-length PIC S9(4) BINARY.
ð2 Vstring-text.
ð3 Vstring-char PIC X
OCCURS ð TO 256 TIMES
DEPENDING ON Vstring-length
of PICSTR.
ð1 LILIAN PIC S9(9) BINARY.
ð1 FC.
ð2 Condition-Token-Value.
COPY CEEIGZCT.
ð3 Case-1-Condition-ID.
ð4 Severity PIC S9(4) COMP.
ð4 Msg-No PIC S9(4) COMP.
ð3 Case-2-Condition-ID
REDEFINES Case-1-Condition-ID.
ð4 Class-Code PIC S9(4) COMP.
ð4 Cause-Code PIC S9(4) COMP.
ð3 Case-Sev-Ctl PIC X.
ð3 Facility-ID PIC XXX.
ð2 I-S-Info PIC S9(9) COMP.
PROCEDURE DIVISION.
PARA-CBLDAYS.
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
\\ Specify input date and length \\
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
MOVE 16 TO Vstring-length of CHRDATE.
MOVE '1 January 2ððð'
TO Vstring-text of CHRDATE.
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
\\ Specify a picture string that describes \\
\\ input date, and the picture string's length.\\
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
MOVE 25 TO Vstring-length of PICSTR.
MOVE 'ZD Mmmmmmmmmmmmmmz YYYY'
TO Vstring-text of PICSTR.
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
\\ Call CEEDAYS to convert input date to a \\
\\ Lilian date \\
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
CALL 'CEEDAYS' USING CHRDATE, PICSTR,
LILIAN, FC.
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
\\ If CEEDAYS runs successfully, display result\\
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
IF CEEððð of FC THEN
DISPLAY Vstring-text of CHRDATE
' is Lilian day: ' LILIAN
ELSE
DISPLAY 'CEEDAYS failed with msg '
Msg-No of FC UPON CONSOLE
STOP RUN
END-IF.
GOBACK.
Syntax
55──CALL──"CEEDYWK"──USING──input_Lilian_date──,──output_day_no──,─────5
5──fc──.──────────────────────────────────────────────────────────────5%
input_Lilian_date (input)
A 32-bit binary integer representing the Lilian date, the number of days since 14
October 1582.
For example, 16 May 1988 is day number 148138. The valid range of
input_Lilian_date is between 1 and 3,074,324 (15 October 1582 and 31 December
9999).
output_day_no (output)
A 32-bit binary integer representing input_Lilian_date's day-of-week: 1 equals
Sunday, 2 equals Monday, ..., 7 equals Saturday.
If input_Lilian_date is invalid, output_day_no is set to 0 and CEEDYWK terminates
with a non-CEE000 symbolic feedback code.
fc (output)
A 12-byte feedback code (optional), that indicates the result of this service.
The following symbolic conditions can result from this service:
Symbolic
Feedback Message
Code Severity Number Message Text
CEE000 0 — The service completed successfully.
CEE2EG 3 2512 The Lilian date value passed in a call to
CEEDATE or CEEDYWK was not within the
supported range.
Example
CBL LIB,APOST
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
\\ \\
\\ Function: Call CEEDYWK to calculate the \\
\\ day of the week from Lilian date \\
\\ \\
\\ In this example, a call is made to CEEDYWK \\
\\ to return the day of the week on which a \\
\\ Lilian date falls. (A Lilian date is the \\
\\ number of days since 14 October 1582) \\
\\ \\
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
IDENTIFICATION DIVISION.
PROGRAM-ID. CBLDYWK.
DATA DIVISION.
WORKING-STORAGE SECTION.
ð1 LILIAN PIC S9(9) BINARY.
ð1 DAYNUM PIC S9(9) BINARY.
ð1 IN-DATE.
PROCEDURE DIVISION.
PARA-CBLDAYS.
\\ Call CEEDAYS to convert date of 6/2/88 to
\\ Lilian representation
MOVE 6 TO Vstring-length of IN-DATE.
MOVE '6/2/88' TO Vstring-text of IN-DATE(1:6).
MOVE 8 TO Vstring-length of PICSTR.
MOVE 'MM/DD/YY' TO Vstring-text of PICSTR(1:8).
CALL 'CEEDAYS' USING IN-DATE, PICSTR,
LILIAN, FC.
PARA-CBLDYWK.
GOBACK.
Syntax
55──CALL──"CEEGMT"──USING──output_GMT_Lilian──,──output_GMT_seconds────5
5──,──fc──.───────────────────────────────────────────────────────────5%
output_GMT_Lilian (output)
A 32-bit binary integer representing the current date in Greenwich, England, in the
Lilian format (the number of days since 14 October 1582).
For example, 16 May 1988 is day number 148138. If GMT is not available from
the system, output_GMT_Lilian is set to 0 and CEEGMT terminates with a
non-CEE000 symbolic feedback code.
output_GMT_seconds (output)
A 64-bit double floating-point number representing the current date and time in
Greenwich, England, as the number of seconds since 00:00:00 on 14 October
1582, not counting leap seconds.
For example, 00:00:01 on 15 October 1582 is second number 86,401 (24*60*60 +
01). 19:00:01.078 on 16 May 1988 is second number 12,799,191,601.078. If GMT
is not available from the system, output_GMT_seconds is set to 0 and CEEGMT
terminates with a non-CEE000 symbolic feedback code.
fc (output)
A 12-byte feedback code (optional), that indicates the result of this service.
The following symbolic conditions can result from this service:
Symbolic
Feedback Message
Code Severity Number Message Text
CEE000 0 — The service completed successfully.
CEE2E6 3 2502 The UTC/GMT was not available from the
system.
Usage Notes
CEEDATE converts output_GMT_Lilian to a character date, and CEEDATM con-
verts output_GMT_seconds to a character timestamp.
In order for the results of this service to be meaningful, your system's clock must
be set to the local time and the environment variable TZ must be set correctly.
See “Setting Environment Variables” on page 128 for details on how to set envi-
ronment variables and “Run-Time Environment Variables” on page 130 for specific
information about the TZ environment variable.
The values returned by CEEGMT are handy for elapsed time calculations. For
example, you can calculate the time elapsed between two calls to CEEGMT by
calculating the differences between the returned values.
CEEUTC is identical to this service.
Example
CBL LIB,APOST
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
\\ \\
\\ Function: Call CEEGMT to get current \\
\\ Greenwich Mean Time \\
\\ \\
\\ In this example, a call is made to CEEGMT \\
\\ to return the current GMT as a Lilian date \\
\\ and as Lilian seconds. The results are \\
\\ displayed. \\
\\ \\
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
IDENTIFICATION DIVISION.
PROGRAM-ID. IGZTGMT.
DATA DIVISION.
WORKING-STORAGE SECTION.
ð1 LILIAN PIC S9(9) BINARY.
ð1 SECS COMP-2.
ð1 FC.
ð2 Condition-Token-Value.
COPY CEEIGZCT.
ð3 Case-1-Condition-ID.
ð4 Severity PIC S9(4) COMP.
ð4 Msg-No PIC S9(4) COMP.
ð3 Case-2-Condition-ID
REDEFINES Case-1-Condition-ID.
ð4 Class-Code PIC S9(4) COMP.
ð4 Cause-Code PIC S9(4) COMP.
ð3 Case-Sev-Ctl PIC X.
ð3 Facility-ID PIC XXX.
ð2 I-S-Info PIC S9(9) COMP.
PROCEDURE DIVISION.
PARA-CBLGMT.
CALL 'CEEGMT' USING LILIAN , SECS , FC.
IF CEEððð of FC THEN
DISPLAY 'The current GMT is also '
'known as Lilian day: ' LILIAN
DISPLAY 'The current GMT in Lilian '
GOBACK.
Syntax
55──CALL──"CEEGMTO"──USING──offset_hours──,──offset_minutes──,─────────5
5──offset_seconds──,──fc──.───────────────────────────────────────────5%
offset_hours (output)
A 32-bit binary integer representing the offset from GMT to local time, in hours.
For example, for Pacific Standard Time, offset_hours equals -8.
The range of offset_hours is -12 to +13 (+13 = Daylight Savings Time in the +12
time zone).
If local time offset is not available, offset_hours equals 0 and CEEGMTO termi-
nates with a non-CEE000 symbolic feedback code.
offset_minutes (output)
A 32-bit binary integer representing the number of additional minutes that local time
is ahead of or behind GMT.
The range of offset_minutes is 0 to 59.
If the local time offset is not available, offset_minutes equals 0 and CEEGMTO
terminates with a non-CEE000 symbolic feedback code.
offset_seconds (output)
A 64-bit double floating-point number representing the offset from GMT to local
time, in seconds.
For example, Pacific Standard Time is eight hours behind GMT. If local time is in
the Pacific time zone during standard time, CEEGMTO would return -28,800 (-8 *
60 * 60). The range of offset_seconds is -43,200 to +46,800. offset_seconds can
be used with CEEGMT to calculate local date and time. See “CEEGMT—Get
Current Greenwich Mean Time” on page 505 for more information.
If the local time offset is not available from the system, offset_seconds is set to 0
and CEEGMTO terminates with a non-CEE000 symbolic feedback code.
fc (output)
A 12-byte feedback code (optional), that indicates the result of this service.
The following symbolic conditions can result from this service:
Symbolic
Feedback Message
Code Severity Number Message Text
CEE000 0 — The service completed successfully.
CEE2E7 3 2503 The offset from UTC/GMT to local time was
not available from the system.
Usage Notes
CEEDATM is used to convert offset_seconds to a character timestamp.
In order for the results of this service to be meaningful, your system's clock must
be set to the local time and the environment variable TZ must be set correctly.
See “Setting Environment Variables” on page 128 for details on how to set envi-
ronment variables and “Run-Time Environment Variables” on page 130 for specific
information about the TZ environment variable.
Example
CBL LIB,APOST
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
\\ \\
\\ Function: Call CEEGMTO to get offset from \\
\\ Greenwich Mean Time to local \\
\\ time \\
\\ \\
\\ In this example, a call is made to CEEGMTO \\
\\ to return the offset from GMT to local time \\
\\ as separate binary integers representing \\
\\ offset hours, minutes, and seconds. The \\
\\ results are displayed. \\
\\ \\
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
IDENTIFICATION DIVISION.
PROGRAM-ID. IGZTGMTO.
DATA DIVISION.
WORKING-STORAGE SECTION.
IF CEEððð of FC THEN
DISPLAY 'Local time differs from GMT '
'by: ' HOURS ' hours, '
MINUTES ' minutes, OR '
SECONDS ' seconds. '
ELSE
DISPLAY 'CEEGMTO failed with msg '
Msg-No of FC UPON CONSOLE
STOP RUN
END-IF.
GOBACK.
Syntax
55──CALL──"CEEISEC"──USING──input_year──,──input_months──,─────────────5
5──input_day──,──input_hours──,──input_minutes──,──input_seconds──,────5
5──input_milliseconds──,──output_seconds──,──fc──.────────────────────5%
input_year (input)
A 32-bit binary integer representing the year.
The range of valid values for input_year is 1582 to 9999, inclusive.
input_month (input)
A 32-bit binary integer representing the month.
The range of valid values for input_month is 1 to 12.
input_day (input)
A 32-bit binary integer representing the day.
The range of valid values for input_day is 1 to 31.
input_hours (input)
A 32-bit binary integer representing the hours.
The range of valid values for input_hours is 0 to 23.
input_minutes (input)
A 32-bit binary integer representing the minutes.
The range of valid values for input_minutes is 0 to 59.
input_seconds (input)
A 32-bit binary integer representing the seconds.
The range of valid values for input_seconds is 0 to 59.
input_milliseconds (input)
A 32-bit binary integer representing milliseconds.
The range of valid values for input_milliseconds is 0 to 999.
output_seconds (output)
A 64-bit double floating-point number representing the number of seconds since
00:00:00 on 14 October 1582, not counting leap seconds.
For example, 00:00:01 on 15 October 1582 is second number 86,401 (24*60*60 +
01). The valid range of output_seconds is 86,400 to 265,621,679,999.999
(23:59:59.999 31 December 9999).
If any input values are invalid, output_seconds is set to zero.
To convert output_seconds to a Lilian day number, divide output_seconds by
86,400 (the number of seconds in a day).
fc (output)
A 12-byte feedback code (optional), that indicates the result of this service.
The following symbolic conditions can result from this service:
Symbolic
Feedback Message
Code Severity Number Message Text
CEE000 0 — The service completed successfully.
CEE2EE 3 2510 The hours value in a call to CEEISEC or
CEESECS was not recognized.
Symbolic
Feedback Message
Code Severity Number Message Text
CEE2EF 3 2511 The day parameter passed in a CEEISEC
call was invalid for year and month speci-
fied.
CEE2EH 3 2513 The input date passed in a CEEISEC,
CEEDAYS, or CEESECS call was not within
the supported range.
CEE2EI 3 2514 The year value passed in a CEEISEC call
was not within the supported range.
CEE2EJ 3 2515 The milliseconds value in a CEEISEC call
was not recognized.
CEE2EK 3 2516 The minutes value in a CEEISEC call was
not recognized.
CEE2EL 3 2517 The month value in a CEEISEC call was not
recognized.
CEE2EN 3 2519 The seconds value in a CEEISEC call was
not recognized.
Usage Notes
The inverse of CEEISEC is CEESECI, which converts number of seconds to
integer year, month, day, hour, minute, second, and millisecond.
Example
CBL LIB,APOST
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
\\ \\
\\ Function: Call CEEISEC to convert integers \\
\\ to seconds \\
\\ \\
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
IDENTIFICATION DIVISION.
PROGRAM-ID. CBLISEC.
DATA DIVISION.
WORKING-STORAGE SECTION.
ð1 YEAR PIC S9(9) BINARY.
ð1 MONTH PIC S9(9) BINARY.
ð1 DAYS PIC S9(9) BINARY.
GOBACK.
CEELOCT performs the same function as calling the CEEGMT, CEEGMTO, and
CEEDATM date and time services separately. CEELOCT, however, performs the same
services with much greater speed.
Syntax
55──CALL──"CEELOCT"──USING──output_Lilian──,──output_seconds──,────────5
5──output_Gregorian──,──fc──.─────────────────────────────────────────5%
output_Lilian (output)
A 32-bit binary integer representing the current local date in the Lilian format, that
is, day 1 equals 15 October 1582, day 148,887 equals 4 June 1990.
If the local time is not available from the system, output_Lilian is set to 0 and
CEELOCT terminates with a non-CEE000 symbolic feedback code.
output_seconds (output)
A 64-bit double-floating point number representing the current local date and time
as the number of seconds since 00:00:00 on 14 October 1582, not counting leap
seconds. For example, 00:00:01 on 15 October 1582 is second number 86,401
(24*60*60 + 01). 19:00:01.078 on 4 June 1990 is second number
12,863,905,201.078.
If the local time is not available from the system, output_seconds is set to 0 and
CEELOCT terminates with a non-CEE000 symbolic feedback code.
output_Gregorian (output)
A 17-byte fixed-length character string in the form YYYYMMDDHHMISS999 repres-
enting local year, month, day, hour, minute, second, and millisecond.
If the format of output_Gregorian does not meet your needs, you can use the
CEEDATM callable service to convert output_seconds to another format.
fc (output)
A 12-byte feedback code (optional), that indicates the result of this service.
The following symbolic conditions can result from this service:
Symbolic
Feedback Message
Code Severity Number Message Text
CEE000 0 — The service completed successfully.
CEE2F3 3 2531 The local time was not available from the
system.
Usage Notes
You can use the CEEGMT callable service to determine Greenwich Mean Time
(GMT).
You can use the CEEGMTO callable service to obtain the offset from GMT to local
time.
The character value returned by CEELOCT is designed to match that produced by
existing intrinsic functions. The numeric values returned can be used to simplify
date calculations.
Example
CBL LIB,APOST
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
\\ \\
\\ Function: Call CEELOCT to get current \\
\\ local time \\
\\ \\
\\ In this example, a call is made to CEELOCT \\
\\ to return the current local time in Lilian \\
\\ days (the number of days since 14 October \\
\\ 1582), Lilian seconds (the number of \\
\\ seconds since ðð:ðð:ðð 14 October 1582), \\
\\ and a Gregorian string (in the form \\
\\ YYYMMDDMISS999). The Gregorian character \\
\\ string is then displayed. \\
\\ \\
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
IDENTIFICATION DIVISION.
PROGRAM-ID. CBLLOCT.
DATA DIVISION.
WORKING-STORAGE SECTION.
ð1 LILIAN PIC S9(9) BINARY.
ð1 SECONDS COMP-2.
ð1 GREGORN PIC X(17).
ð1 FC.
ð2 Condition-Token-Value.
COPY CEEIGZCT.
ð3 Case-1-Condition-ID.
ð4 Severity PIC S9(4) COMP.
ð4 Msg-No PIC S9(4) COMP.
ð3 Case-2-Condition-ID
REDEFINES Case-1-Condition-ID.
ð4 Class-Code PIC S9(4) COMP.
ð4 Cause-Code PIC S9(4) COMP.
ð3 Case-Sev-Ctl PIC X.
ð3 Facility-ID PIC XXX.
ð2 I-S-Info PIC S9(9) COMP.
PROCEDURE DIVISION.
PARA-CBLLOCT.
CALL 'CEELOCT' USING LILIAN, SECONDS,
GREGORN, FC.
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
\\ If CEELOCT runs successfully, display \\
\\ Gregorian character string \\
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
IF CEEððð of FC THEN
DISPLAY 'Local Time is ' GREGORN
ELSE
DISPLAY 'CEELOCT failed with msg '
Msg-No of FC UPON CONSOLE
STOP RUN
END-IF.
GOBACK.
Syntax
55──CALL──"CEEQCEN"──USING──century_start──,──fc──.───────────────────5%
century_start (output)
An integer between 0 and 100 indicating the year on which the century window is
based.
For example, if the date and time callable services default is in effect, all 2-digit
years lie within the 100-year window starting 80 years prior to the system date.
CEEQCEN then returns the value 80. An 80 value indicates to the date and time
callable services that, in 1997, all 2-digit years lie within the 100-year window
starting 80 years before the system date (between 1917 and 2016, inclusive).
fc (output)
A 12-byte feedback code (optional), that indicates the result of this service.
The following symbolic conditions can result from this service:
Symbolic
Feedback Message
Code Severity Number Message Text
CEE000 0 — The service completed successfully.
Example
CBL LIB,APOST
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
\\ \\
\\ Function: Call CEEQCEN to query the \\
\\ date and time callable services \\
\\ century window \\
\\ \\
\\ In this example, CEEQCEN is called to query \\
\\ the date at which the century window starts \\
\\ The century window is the 1ðð-year window \\
\\ within which the date and time callable \\
\\ services assume all two-digit years lie. \\
\\ \\
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
IDENTIFICATION DIVISION.
PROGRAM-ID. CBLQCEN.
DATA DIVISION.
WORKING-STORAGE SECTION.
ð1 STARTCW PIC S9(9) BINARY.
ð1 FC.
ð2 Condition-Token-Value.
COPY CEEIGZCT.
ð3 Case-1-Condition-ID.
ð4 Severity PIC S9(4) COMP.
ð4 Msg-No PIC S9(4) COMP.
ð3 Case-2-Condition-ID
REDEFINES Case-1-Condition-ID.
ð4 Class-Code PIC S9(4) COMP.
ð4 Cause-Code PIC S9(4) COMP.
ð3 Case-Sev-Ctl PIC X.
ð3 Facility-ID PIC XXX.
ð2 I-S-Info PIC S9(9) COMP.
PROCEDURE DIVISION.
PARA-CBLQCEN.
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
\\ Call CEEQCEN to return the start of the \\
\\ century window \\
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
GOBACK.
Syntax
55──CALL──"CEESCEN"──USING──century_start──,──fc──.───────────────────5%
century_start
An integer between 0 and 100, setting the century window.
A value of 80, for example, places all two-digit years within the 100-year window
starting 80 years before the system date. In 1997, therefore, all two-digit years are
assumed to represent dates between 1917 and 2016, inclusive.
fc (output)
A 12-byte feedback code (optional), that indicates the result of this service.
The following symbolic conditions can result from this service:
Symbolic
Feedback Message
Code Severity Number Message Text
CEE000 0 — The service completed successfully.
CEE2E6 3 2502 The UTC/GMT was not available from the
system.
CEE2F5 3 2533 The value passed to CEESCEN was not
between 0 and 100.
Example
CBL LIB,APOST
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
\\ \\
\\ Function: Call CEESCEN to set the \\
\\ date and time callable services \\
\\ century window \\
\\ \\
\\ In this example, CEESCEN is called to change \\
\\ the start of the century window to 3ð years \\
\\ before the system date. CEEQCEN is then \\
\\ called to query that the change made. A \\
\\ message that this has been done is then \\
\\ displayed. \\
\\ \\
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
IDENTIFICATION DIVISION.
PROGRAM-ID. CBLSCEN.
DATA DIVISION.
WORKING-STORAGE SECTION.
ð1 STARTCW PIC S9(9) BINARY.
ð1 FC.
ð2 Condition-Token-Value.
COPY CEEIGZCT.
ð3 Case-1-Condition-ID.
ð4 Severity PIC S9(4) COMP.
ð4 Msg-No PIC S9(4) COMP.
ð3 Case-2-Condition-ID
REDEFINES Case-1-Condition-ID.
ð4 Class-Code PIC S9(4) COMP.
ð4 Cause-Code PIC S9(4) COMP.
ð3 Case-Sev-Ctl PIC X.
ð3 Facility-ID PIC XXX.
ð2 I-S-Info PIC S9(9) COMP.
PROCEDURE DIVISION.
PARA-CBLSCEN.
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
\\ Specify 3ð as century start, and two-digit
\\ years will be assumed to lie in the
\\ 1ðð-year window starting 3ð years before
\\ the system date.
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
MOVE 3ð TO STARTCW.
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
\\ Call CEESCEN to change the start of the century
\\ window.
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
CALL 'CEESCEN' USING STARTCW, FC.
IF NOT CEEððð of FC THEN
DISPLAY 'CEESCEN failed with msg '
Msg-No of FC UPON CONSOLE
STOP RUN
END-IF.
PARA-CBLQCEN.
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
\\ Call CEEQCEN to return the start of the century
\\ window
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
CALL 'CEEQCEN' USING STARTCW, FC.
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
\\ CEEQCEN has no non-zero feedback codes to
\\ check, so just display result.
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
DISPLAY 'The start of the century '
'window is: ' STARTCW
GOBACK.
Syntax
55──CALL──"CEESECI"──USING──input_seconds──,──output_year──,───────────5
5──output_month──,──output_day──,──output_hours──,──output_minutes─────5
5──,──output_seconds──,──output_milliseconds──,──fc──.────────────────5%
input_seconds
A 64-bit double floating-point number representing the number of seconds since
00:00:00 on 14 October 1582, not counting leap seconds.
For example, 00:00:01 on 15 October 1582 is second number 86,401 (24*60*60 +
01). The range of valid values for input_seconds is 86,400 to 265,621,679,999.999
(23:59:59.999 31 December 9999).
If input_seconds is invalid, all output parameters except the feedback code are set
to 0.
output_year (output)
A 32-bit binary integer representing the year.
The range of valid values for output_year is 1582 to 9999, inclusive.
output_month (output)
A 32-bit binary integer representing the month.
The range of valid values for output_month is 1 to 12.
output_day (output)
A 32-bit binary integer representing the day.
The range of valid values for output_day is 1 to 31.
output_hours (output)
A 32-bit binary integer representing the hour.
The range of valid values for output_hours is 0 to 23.
output_minutes (output)
A 32-bit binary integer representing the minutes.
The range of valid values for output_minutes is 0 to 59.
output_seconds (output)
A 32-bit binary integer representing the seconds.
The range of valid values for output_seconds is 0 to 59.
output_milliseconds (output)
A 32-bit binary integer representing milliseconds.
The range of valid values for output_milliseconds is 0 to 999.
fc (output)
A 12-byte feedback code (optional), that indicates the result of this service.
The following symbolic conditions can result from this service:
Symbolic
Feedback Message
Code Severity Number Message Text
CEE000 0 — The service completed successfully.
CEE2E9 3 2505 The input_seconds value in a call to
CEEDATM or CEESECI was not within the
supported range.
Usage Notes
The inverse of CEESECI is CEEISEC, which converts separate binary integers
representing year, month, day, hour, second, and millisecond to a number of
seconds.
If the input value is a Lilian date instead of seconds, multiply the Lilian date by
86,400 (number of seconds in a day), and pass the new value to CEESECI.
Example
CBL LIB,APOST
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
\\ \\
\\ Function: Call CEESECI to convert seconds \\
\\ to integers \\
\\ \\
\\ In this example a call is made to CEESECI \\
\\ to convert a number representing the number \\
\\ of seconds since ðð:ðð:ðð 14 October 1582 \\
DATA DIVISION.
WORKING-STORAGE SECTION.
ð1 INSECS COMP-2.
ð1 YEAR PIC S9(9) BINARY.
ð1 MONTH PIC S9(9) BINARY.
ð1 DAYS PIC S9(9) BINARY.
ð1 HOURS PIC S9(9) BINARY.
ð1 MINUTES PIC S9(9) BINARY.
ð1 SECONDS PIC S9(9) BINARY.
ð1 MILLSEC PIC S9(9) BINARY.
ð1 IN-DATE.
ð2 Vstring-length PIC S9(4) BINARY.
ð2 Vstring-text.
ð3 Vstring-char PIC X,
OCCURS ð TO 256 TIMES
DEPENDING ON Vstring-length
of IN-DATE.
ð1 PICSTR.
ð2 Vstring-length PIC S9(4) BINARY.
ð2 Vstring-text.
ð3 Vstring-char PIC X,
OCCURS ð TO 256 TIMES
DEPENDING ON Vstring-length
of PICSTR.
ð1 FC.
ð2 Condition-Token-Value.
COPY CEEIGZCT.
ð3 Case-1-Condition-ID.
ð4 Severity PIC S9(4) COMP.
ð4 Msg-No PIC S9(4) COMP.
ð3 Case-2-Condition-ID
REDEFINES Case-1-Condition-ID.
ð4 Class-Code PIC S9(4) COMP.
ð4 Cause-Code PIC S9(4) COMP.
ð3 Case-Sev-Ctl PIC X.
ð3 Facility-ID PIC XXX.
ð2 I-S-Info PIC S9(9) COMP.
PROCEDURE DIVISION.
PARA-CBLSECS.
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
\\ Call CEESECS to convert timestamp of 6/2/88
PARA-CBLSECI.
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
\\ Call CEESECI to convert seconds to integers
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
CALL 'CEESECI' USING INSECS, YEAR, MONTH,
DAYS, HOURS, MINUTES,
SECONDS, MILLSEC, FC.
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
\\ If CEESECI runs successfully, display results
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
IF CEEððð of FC THEN
DISPLAY 'Input seconds of ' INSECS
' represents:'
DISPLAY ' Year......... ' YEAR
DISPLAY ' Month........ ' MONTH
DISPLAY ' Day.......... ' DAYS
DISPLAY ' Hour......... ' HOURS
DISPLAY ' Minute....... ' MINUTES
DISPLAY ' Second....... ' SECONDS
DISPLAY ' Millisecond.. ' MILLSEC
ELSE
DISPLAY 'CEESECI failed with msg '
Msg-No of FC UPON CONSOLE
STOP RUN
END-IF.
GOBACK.
Syntax
55──CALL──"CEESECS"──USING──input_timestamp──,──picture_string──,──────5
5──output_seconds──,──fc──.───────────────────────────────────────────5%
input_timestamp (input)
A halfword length-prefixed character string, representing a date or timestamp in a
format matching that specified by picture_string.
The character string must contain between 5 and 80 picture characters, inclusive.
input_timestamp can contain leading or trailing blanks. Parsing begins with the first
nonblank character (unless the picture string itself contains leading blanks; in this
case, CEESECS skips exactly that many positions before parsing begins).
After a valid date is parsed, as determined by the format of the date you specify in
picture_string, all remaining characters are ignored by CEESECS. Valid dates
range between and including the dates 15 October 1582 to 31 December 9999. A
full date must be specified. Valid times range from 00:00:00.000 to 23:59:59.999.
If any part or all of the time value is omitted, zeros are substituted for the
remaining values. For example:
1992-ð5-17-19:ð2 is equivalent to 1992-ð5-17-19:ð2:ðð
1992-ð5-17 is equivalent to 1992-ð5-17-ðð:ðð:ðð
picture_string (input)
A halfword length-prefixed character string, indicating the format of the date or
timestamp value specified in input_timestamp.
Each character in the picture_string represents a character in input_timestamp.
For example, if you specify MMDDYY HH.MI.SS as the picture_string, CEESECS
reads an input_char_date of 060288 15.35.02 as 3:35:02 PM on 02 June 1988. If
delimiters such as the slash (/) appear in the picture string, leading zeros can be
omitted. For example, the following calls to CEESECS all assign the same value
to variable secs:
CALL CEESECS USING '92/ð6/ð3 15.35.ð3',
'YY/MM/DD HH.MI.SS', secs, fc.
CALL CEESECS USING '92/6/3 15.35.ð3',
'YY/MM/DD HH.MI.SS', secs, fc.
CALL CEESECS USING '92/6/3 3.35.ð3 PM',
'YY/MM/DD HH.MI.SS AP', secs, fc.
CALL CEESECS USING '92.155 3.35.ð3 pm',
'YY.DDD HH.MI.SS AP', secs, fc.
output_seconds (output)
A 64-bit double floating-point number representing the number of seconds since
00:00:00 on 14 October 1582, not counting leap seconds. For example, 00:00:01
on 15 October 1582 is second 86,401 (24*60*60 + 01) in the Lilian format.
19:00:01.12 on 16 May 1988 is second 12,799,191,601.12.
The largest value represented is 23:59:59.999 on 31 December 9999, which is
second 265,621,679,999.999 in the Lilian format.
A 64-bit double floating-point value can accurately represent approximately 16 sig-
nificant decimal digits without loss of precision. Therefore, accuracy is available to
the nearest millisecond (15 decimal digits).
If input_timestamp does not contain a valid date or timestamp, output_seconds is
set to 0 and CEESECS terminates with a non-CEE000 symbolic feedback code.
Elapsed time calculations are performed easily on the output_seconds, because it
represents elapsed time. Leap year and end-of-year anomalies do not affect the
calculations.
fc (output)
A 12-byte feedback code (optional), that indicates the result of this service.
The following symbolic conditions can result from this service:
Symbolic
Feedback Message
Code Severity Number Message Text
CEE000 0 — The service completed successfully.
CEE2EB 3 2507 Insufficient data was passed to CEEDAYS
or CEESECS. The Lilian value was not cal-
culated.
CEE2EC 3 2508 The date value passed to CEEDAYS or
CEESECS was invalid.
CEE2ED 3 2509 The Japanese or Republic of China Era
passed to CEEDAYS or CEESECS was not
recognized.
Symbolic
Feedback Message
Code Severity Number Message Text
CEE2EE 3 2510 The hours value in a call to CEEISEC or
CEESECS was not recognized.
CEE2EH 3 2513 The input date passed in a CEEISEC,
CEEDAYS, or CEESECS call was not within
the supported range.
CEE2EK 3 2516 The minutes value in a CEEISEC call was
not recognized.
CEE2EL 3 2517 The month value in a CEEISEC call was not
recognized.
CEE2EM 3 2518 An invalid picture string was specified in a
call to a date/time service.
CEE2EN 3 2519 The seconds value in a CEEISEC call was
not recognized.
CEE2EP 3 2521 The Japanese (<JJJJ>) or Chinese
(<CCCC>) year-within-Era value passed to
CEEDAYS or CEESECS was zero.
CEE2ET 3 2525 CEESECS detected non-numeric data in a
numeric field, or the timestamp string did not
match the picture string.
Usage Notes
The inverse of CEESECS is CEEDATM, which converts output_seconds to char-
acter format.
By default, 2-digit years lie within the 100 year range starting 80 years prior to the
system date. Thus, in 1997, all 2-digit years represent dates between 1917 and
2016, inclusive. You can change this range by using the callable service
CEESCEN.
Example
CBL LIB,APOST
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
\\ \\
\\ Function: Call CEESECS to convert \\
\\ timestamp to number of seconds \\
\\ \\
\\ In this example, calls are made to CEESECS \\
\\ to convert two timestamps to the number of \\
\\ seconds since ðð:ðð:ðð 14 October 1582. \\
\\ The Lilian seconds for the earlier \\
\\ timestamp are then subtracted from the \\
\\ Lilian seconds for the later timestamp \\
\\ to determine the number of between the \\
\\ two. This result is displayed. \\
\\ \\
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
IDENTIFICATION DIVISION.
PROGRAM-ID. CBLSECS.
DATA DIVISION.
WORKING-STORAGE SECTION.
ð1 SECOND1 COMP-2.
ð1 SECOND2 COMP-2.
ð1 TIMESTP.
ð2 Vstring-length PIC S9(4) BINARY.
ð2 Vstring-text.
ð3 Vstring-char PIC X,
OCCURS ð TO 256 TIMES
DEPENDING ON Vstring-length
of TIMESTP.
ð1 TIMESTP2.
ð2 Vstring-length PIC S9(4) BINARY.
ð2 Vstring-text.
ð3 Vstring-char PIC X,
OCCURS ð TO 256 TIMES
DEPENDING ON Vstring-length
of TIMESTP2.
ð1 PICSTR.
ð2 Vstring-length PIC S9(4) BINARY.
ð2 Vstring-text.
ð3 Vstring-char PIC X,
OCCURS ð TO 256 TIMES
DEPENDING ON Vstring-length
of PICSTR.
ð1 FC.
ð2 Condition-Token-Value.
COPY CEEIGZCT.
ð3 Case-1-Condition-ID.
ð4 Severity PIC S9(4) COMP.
ð4 Msg-No PIC S9(4) COMP.
ð3 Case-2-Condition-ID
REDEFINES Case-1-Condition-ID.
ð4 Class-Code PIC S9(4) COMP.
ð4 Cause-Code PIC S9(4) COMP.
ð3 Case-Sev-Ctl PIC X.
ð3 Facility-ID PIC XXX.
ð2 I-S-Info PIC S9(9) COMP.
PROCEDURE DIVISION.
PARA-SECS1.
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
\\ Specify first timestamp and a picture string
\\ describing the format of the timestamp
\\ as input to CEESECS
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
MOVE 25 TO Vstring-length of TIMESTP.
MOVE '1969-ð5-ð7 12:ð1:ðð.ððð'
TO Vstring-text of TIMESTP.
MOVE 25 TO Vstring-length of PICSTR.
MOVE 'YYYY-MM-DD HH:MI:SS.999'
TO Vstring-text of PICSTR.
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
\\ Call CEESECS to convert the first timestamp
\\ to Lilian seconds
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
CALL 'CEESECS' USING TIMESTP, PICSTR,
SECOND1, FC.
IF NOT CEEððð of FC THEN
DISPLAY 'CEESECS failed with msg '
Msg-No of FC UPON CONSOLE
STOP RUN
END-IF.
PARA-SECS2.
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
\\ Specify second timestamp and a picture string
\\ describing the format of the timestamp as
\\ input to CEESECS.
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
MOVE 25 TO Vstring-length of TIMESTP2.
MOVE '2ððð-ð1-ð1 ðð:ðð:ð1.ððð'
TO Vstring-text of TIMESTP2.
MOVE 25 TO Vstring-length of PICSTR.
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
\\ Call CEESECS to convert the second timestamp
\\ to Lilian seconds
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
CALL 'CEESECS' USING TIMESTP2, PICSTR,
SECOND2, FC.
IF NOT CEEððð of FC THEN
DISPLAY 'CEESECS failed with msg '
Msg-No of FC UPON CONSOLE
STOP RUN
END-IF.
PARA-SECS2.
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
\\ Subtract SECOND2 from SECOND1 to determine the
\\ number of seconds between the two timestamps
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
SUBTRACT SECOND1 FROM SECOND2.
DISPLAY 'The number of seconds between '
Vstring-text OF TIMESTP ' and '
Vstring-text OF TIMESTP2 ' is: ' SECOND2.
GOBACK.
IGZEDT4 returns the current date with a 4-digit year in the form YYYYMMDD.
Syntax
55──CALL──"IGZEDT4"──USING──output_char_date──.───────────────────────5%
output_char_date (output)
An 8-byte fixed-length character string in the form YYYYMMDD representing
current year, month, and day.
Usage Notes
IGZEDT4 is not supported under CICS.
Example
CBL LIB,APOST
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
\\ Function: IGZEDT4 - get current date in the \\
\\ format YYYYMMDD. \\
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
IDENTIFICATION DIVISION.
PROGRAM-ID. CBLEDT4.
DATA DIVISION.
WORKING-STORAGE SECTION.
ð1 CHRDATE PIC S9(8) USAGE DISPLAY.
PROCEDURE DIVISION.
PARA-CBLEDT4.
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
\\ Call IGZEDT4.
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
CALL 'IGZEDT4' USING BY REFERENCE CHRDATE.
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
\\ IGZEDT4 has no non-zero return code to
\\ check, so just display result.
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
DISPLAY 'The current date is: '
CHRDATE
GOBACK.
The date and time callable services messages also contain a symbolic feedback code,
which represents the first 8 bytes of a 12-byte condition token. You can think of the
symbolic feedback code as the nickname for a condition. Note that the callable ser-
vices messages contain a 4-digit message number.
IWZ006S The reference to table table-name by verb number verb-number on line line-
number addressed an area outside the region of the table.
Explanation: When the SSRANGE option is in effect, this message is issued to indicate that a
fixed-length table has been subscripted in a way that exceeds the defined size of the table, or, for
variable-length tables, the maximum size of the table.
The range check was performed on the composite of the subscripts and resulted in an address
outside the region of the table. For variable-length tables, the address is outside the region of the
table defined when all OCCURS DEPENDING ON objects are at their maximum values; the ODO
object's current value is not considered. The check was not performed on individual subscripts.
Programmer Response: Ensure that the value of literal subscripts and/or the value of variable
subscripts as evaluated at run-time do not exceed the subscripted dimensions for subscripted data
in the failing statement.
System Action: The application was terminated.
IWZ007S The reference to variable length group group-name by verb number verb-
number on line line-number addressed an area outside the maximum defined
length of the group.
Explanation: When the SSRANGE option is in effect, this message is issued to indicate that a
variable-length group generated by OCCURS DEPENDING ON has a length that is less than zero,
or is greater than the limits defined in the OCCURS DEPENDING ON clauses.
The range check was performed on the composite length of the group, and not on the individual
OCCURS DEPENDING ON objects.
Programmer Response: Ensure that OCCURS DEPENDING ON objects as evaluated at run-
time do not exceed the maximum number of occurrences of the dimension for tables within the
referenced group item.
System Action: The application was terminated.
IWZ012I Invalid run unit termination occurred while sort or merge is running.
Explanation: A sort or merge initiated by a COBOL program was in progress and one of the
following was attempted:
1. A STOP RUN was issued.
2. A GOBACK or an EXIT PROGRAM was issued within the input procedure or the output proce-
dure of the COBOL program that initiated the sort or merge. Note that the GOBACK and
EXIT PROGRAM statements are allowed in a program called by an input procedure or an
output procedure.
Programmer Response: Change the application so that it does not use one of the above
methods to end the sort or merge.
System Action: The application was terminated.
IWZ013S Sort or merge requested while sort or merge is running in a different thread.
Explanation: Running sort or merge in two or more threads at the same time is not supported.
Programmer Response: Always run sort or merge in the same thread. Alternatively, include
code before each call to the sort or merge that determines if sort or merge is running in another
thread. If sort or merge is running in another thread, then wait for that thread to finish. If it isn't,
then set a flag to indicate sort or merge is running and call sort or merge.
System Action: The thread is terminated.
IWZ026W The SORT-RETURN special register was never referenced, but the current
content indicated the sort or merge operation in program program-name on
line number line-number was unsuccessful. The sort or merge return code
was return code
Explanation: The COBOL source does not contain any references to the sort-return register.
The compiler generates a test after each sort or merge verb. A nonzero return code has been
passed back to the program by Sort/Merge.
Programmer Response: Determine why the Sort/Merge was unsuccessful and fix the problem.
Explanation: The generated code has truncated an intermediate result (that is, temporary
storage used during an arithmetic calculation) to 30 digits; some of the truncated digits were not 0.
Programmer Response: See Appendix C, “Intermediate Results and Arithmetic Precision” on
page 471 for a description of intermediate results.
System Action: No system action was taken.
IWZ037I The flow of control in program program-name proceeded beyond the last line
of the program. Control returned to the caller of the program program-name
Explanation: The program did not have a terminator (STOP, GOBACK, or EXIT), and control fell
through the last instruction.
Programmer Response: Check the logic of the program. Sometimes this error occurs because
of one of the following logic errors:
The last paragraph in the program was only supposed to receive control as the result of a
PERFORM statement, but due to a logic error it was branched to by a GO TO statement.
The last paragraph in the program was executed as the result of a “fall-through” path, and
there was no statement at the end of the paragraph to end the program.
System Action: The application was terminated.
Explanation: The length value in a reference modification specification was not equal to 1. The
length value must be equal to 1.
Programmer Response: Check the indicated line number in the program to ensure that any ref-
erence modified length values are (or will resolve to) 1.
System Action: The application was terminated.
Explanation: An operation was attempted on data defined with a separate sign. The value in the
sign position was not a plus (+) or a minus (-).
Programmer Response: This error might have occurred because of a REDEFINES clause
involving the sign position or a group move involving the sign position, or the position was never
initialized. Check for the above cases.
System Action: The application was terminated.
Explanation: The specific method is not supported for the class of the current object reference.
Programmer Response: Check the indicated line number in the program to ensure that the
class of the current object reference supports the method being invoked.
System Action: The application was terminated.
IWZ047S Unable to invoke method method-name on line number line number in class
class-name.
Explanation: The specific method is not supported for the class of the current object reference.
Programmer Response: Check the indicated line number in the class to ensure that the class
of the current object reference supports the method being invoked.
System Action: The application was terminated.
Explanation: The value of zero raised to the power zero occurred in a library routine.
The value of zero raised to the power zero is undefined in COBOL. If a SIZE ERROR clause had
appeared on the statement in question, the SIZE ERROR imperative would have been used.
However, no SIZE ERROR clause was present, so the value returned was one.
Programmer Response: Ensure that the program variables in the failing statement have been
set correctly.
System Action: No system action was taken.
Explanation: The value of zero raised to a negative power occurred in a library routine.
The value of zero raised to a negative number is not defined. If a SIZE ERROR clause had
appeared on the statement in question, the SIZE ERROR imperative would have been used.
However, no SIZE ERROR clause was present.
Programmer Response: Ensure that the program variables in the failing statement have been
set correctly.
System Action: The application was terminated.
Explanation: A number was generated in the program that is too large to be represented in
floating point.
Programmer Response: You need to modify the program appropriately to avoid an overflow.
System Action: The application was terminated.
Explanation: A floating point calculation has produced an illegal result. Floating point calcu-
lations are done using IEEE floating point arithmetic, which can produce results called NaN (Not a
Number). For example, the result of 0 divided by 0 is NaN.
Programmer Response: Modify the program to test the arguments to this operation so that NaN
is not produced.
System Action: The application was terminated.
IWZ055W An underflow occurred on conversion to floating point. The result was set
to zero.
Explanation: On conversion to floating point, the negative exponent exceeded the limit of the
hardware. The floating point value was set to zero.
Programmer Response: No action is necessary, although you may want to modify the program
to avoid an underflow.
System Action: No system action was taken.
Explanation: Exponents in fixed point exponentiations may not contain more than nine digits.
The exponent was truncated back to nine digits; some of the truncated digits were not 0.
Programmer Response: No action is necessary, although you may want to adjust the exponent
in the failing statement.
System Action: No system action was taken.
Explanation: Code in a library routine has truncated an intermediate result (that is, temporary
storage used during an arithmetic calculation) back to 30 digits; some of the truncated digits were
not 0.
Programmer Response: See Appendix C, “Intermediate Results and Arithmetic Precision” on
page 471 for a description of intermediate results.
System Action: No system action was taken.
Explanation: Division by zero occurred in a library routine. Division by zero is not defined. If a
SIZE ERROR clause had appeared on the statement in question, the SIZE ERROR imperative
would have been used. However, no SIZE ERROR clause was present.
Programmer Response: Ensure that the program variables in the failing statement have been
set correctly.
System Action: The application was terminated.
IWZ063S An invalid sign was detected in a numeric edited sending field in program-
name on line number line-number.
Explanation: An attempt has been made to move a signed numeric edited field to a signed
numeric or numeric edited receiving field in a MOVE statement. However, the sign position in the
sending field contained a character that was not a valid sign character for the corresponding
PICTURE.
Programmer Response: Ensure that the program variables in the failing statement have been
set correctly.
System Action: The application was terminated.
Explanation: COBOL does not allow reinvocation of an internal program which has begun exe-
cution, but has not yet terminated. For example, if internal programs A and B are siblings of a
containing program, and A calls B and B calls A, this message will be issued.
Programmer Response: Examine your program to eliminate calls to active internal programs.
System Action: The application was terminated.
Explanation: An attempt was made to cancel an active internal program. For example, if internal
programs A and B are siblings in a containing program and A calls B and B cancels A, this
message will be issued.
Programmer Response: Examine your program to eliminate cancellation of active internal pro-
grams.
System Action: The application was terminated.
IWZ066S The length of external data record data-record in program program-name did
not match the existing length of the record.
Explanation: While processing External data records during program initialization, it was deter-
mined that an External data record was previously defined in another program in the run-unit, and
the length of the record as specified in the current program was not the same as the previously
defined length.
Programmer Response: Examine the current file and ensure the External data records are
specified correctly.
System Action: The application was terminated.
IWZ071S ALL subscripted table reference to table table-name by verb number verb-
number on line line-number had an ALL subscript specified for an OCCURS
DEPENDING ON dimension, and the object was less than or equal to 0.
Explanation: When the SSRANGE option is in effect, this message is issued to indicate that
there are 0 occurrences of dimension subscripted by ALL.
The check is performed against the current value of the OCCURS DEPENDING ON OBJECT.
Programmer Response: Ensure that ODO object(s) of ALL-subscripted dimensions of any sub-
scripted items in the indicated statement are positive.
System Action: The application was terminated.
Explanation: The value of the starting position in a reference modification specification was less
than 1, or was greater than the current length of the data item that was being reference modified.
The starting position value must be a positive integer less than or equal to the number of charac-
ters in the reference modified data item.
Programmer Response: Check the value of the starting position in the reference modification
specification.
System Action: The application was terminated.
Explanation: The length value in a reference modification specification was less than or equal to
0. The length value must be a positive integer.
Programmer Response: Check the indicated line number in the program to ensure that any ref-
erence modified length values are (or will resolve to) positive integers.
System Action: The application was terminated.
Explanation: The starting position and length value in a reference modification specification
combine to address an area beyond the end of the reference modified data item. The sum of the
starting position and length value minus one must be less than or equal to the number of charac-
ters in the reference modified data item.
Programmer Response: Check the indicated line number in the program to ensure that any ref-
erence modified start and length values are set such that a reference is not made beyond the
rightmost character of the data item.
System Action: The application was terminated.
Explanation: One or more attributes of an external file did not match between two programs that
defined it.
Programmer Response: Correct the external file. For a summary of file attributes which must
match between definitions of the same external file, see the COBOL Language Reference.
System Action: The application was terminated.
IWZ077W The lengths of the INSPECT data items were not equal. The shorter length
was used.
Explanation: The two data items which appear in a REPLACING or CONVERTING phrase in an
INSPECT statement must have equal lengths, except when the second such item is a figurative
constant. Because of the reference modification for one or both of these data items, the resultant
length values were not equal. The shorter length value is applied to both items, and execution
proceeds.
Programmer Response: You may adjust the operands of unequal length in the failing INSPECT
statement; programmer action is not required.
System Action: No system action was taken.
IWZ078S ALL subscripted table reference to table table-name by verb number verb-
number on line line-number will exceed the upper bound of the table.
Explanation: When the SSRANGE option is in effect, this message is issued to indicate that a
multidimensional table with ALL specified as one or more of the subscripts will result in a reference
beyond the upper limit of the table.
The range check was performed on the composite of the subscripts and the maximum occur-
rences for the ALL subscripted dimensions. For variable-length tables the address is outside the
region of the table defined when all OCCURS DEPENDING ON objects are at their maximum
values; the ODO object's current value is not considered. The check was not performed on indi-
vidual subscripts.
Programmer Response: Ensure that OCCURS DEPENDING ON objects as evaluated at run-
time do not exceed the maximum number of occurrences of the dimension for table items refer-
enced in the failing statement.
System Action: The application was terminated.
Explanation: A dynamic call failed due to one of the reasons listed in the message variants
above. In the above, the value of error-code depends on the execution platform as follows:
AIX: The errno set by load.
OS/2: The return code from the DosLoadModule service.
Windows: The last-error code value set by LoadLibrary.
Programmer Response: Check that you have COBPATH defined. Check that the module
exists: AIX, OS/2, and Windows have graphical interfaces for showing directories and files. You
can also use the ls command on AIX or the dir command on OS/2 and Windows. Check that the
name of the module to be loaded matches the name of the entry called. Check that the module to
be loaded is built correctly using the appropriate cob2 options, for example, to build a DLL on
Windows, the -dll option must be used.
System Action: The application was terminated.
Explanation: Argument-1 for the indicated function must contain at least 1 digit.
Programmer Response: Adjust the number of digits in Argument-1 in the failing statement.
System Action: The application was terminated.
IWZ100S Argument-1 for function function was less than or equal to -1.
Explanation: The total number of digits in argument-1 of the indicated function exceeded 18
digits.
Programmer Response: Adjust the number of digits in argument-1 in the failing statement.
System Action: The application was terminated.
Explanation: A non-digit character other than a decimal point, comma, space or sign (+,-,CR,DB)
was found in argument-1 for NUMVAL/NUMVAL-C function.
Programmer Response: Correct argument-1 for NUMVAL or NUMVAL-C in the indicated state-
ment.
System Action: The application was terminated.
IWZ156S Argument-1 for function function-name was less than zero or greater than 28.
IWZ157S The length of Argument-1 for function function-name was not equal to 1.
IWZ159S Argument-1 for function function-name was less than 1 or greater than
3067671.
IWZ160S Argument-1 for function function-name was less than 16010101 or greater
than 99991231.
IWZ161S Argument-1 for function function-name was less than 1601001 or greater
than 9999365.
Explanation: The input argument to function INTEGER-OF-DAY is less than 1601001 or greater
than 9999365.
Programmer Response: Check that the function argument is in the valid range.
System Action: The application was terminated.
IWZ162S Argument-1 for function function-name was less than 1 or greater than the
number of positions in the program collating sequence.
Explanation: The input argument to function CHAR is less than 1 or greater than the highest
ordinal position in the program collating sequence.
Programmer Response: Check that the function argument is in the valid range.
System Action: The application was terminated.
Explanation: The value of the starting position in a reference modification specification was less
than 1, or was greater than the current length of the function result that was being reference modi-
fied. The starting position value must be a positive integer less than or equal to the number of
characters in the reference modified function result.
Programmer Response: Check the value of the starting position in the reference modification
specification and the length of the actual function result.
System Action: The application was terminated.
Explanation: The length value in a reference modification specification for a function result was
less than or equal to 0. The length value must be a positive integer.
Programmer Response: Check the length value and make appropriate correction.
System Action: The application was terminated.
Explanation: The starting position and length value in a reference modification specification
combine to address an area beyond the end of the reference modified function result. The sum of
the starting position and length value minus one must be less than or equal to the number of
characters in the reference modified function result.
Programmer Response: Check the length of the reference modification specification against the
actual length of the function result and make appropriate corrections.
System Action: The application was terminated.
IWZ168W SYSPUNCH/SYSPCH will default to the system logical output device. The
corresponding environment variable has not been set.
Explanation: COBOL environment names (such as SYSPUNCH/SYSPCH) are used as the envi-
ronment variable names corresponding to the mnemonic names used on ACCEPT and DISPLAY
statements. Set them equal to files, not existing directory names. To set environment variables:
On OS/2 or Windows, use the SET command.
On AIX, use the EXPORT command.
You can set environment variables either temporarily or persistently. For more information, see
“Setting Environment Variables” on page 128.
Programmer Response: If you do not want SYSPUNCH/SYSPCH to default to the screen, set
the corresponding environment variable.
System Action: No system action was taken.
Explanation: An invalid data type was specified as the target of the DISPLAY statement.
Programmer Response: Specify a valid data type. The following data types are not valid:
Data items defined with USAGE IS PROCEDURE-POINTER
Data items defined with USAGE IS OBJECT REFERENCE
Data items or index names defined with USAGE IS INDEX
System Action: The application was terminated.
IWZ172I The string string-name is not a valid suboption of the run-time option option-
name.
IWZ173I The suboption string string-name of the run-time option option-name must be
number of characters long. The default will be used.
Explanation: The number of characters for the suboption string string-name of run-time option
option-name is invalid.
Programmer Response: If you do not want to accept the default, specify a valid character
length. See Chapter 11, “Run-Time Options” on page 193
System Action: The default value will be used.
IWZ174I The suboption string string-name of the run-time option option-name contains
one or more invalid characters. The default will be used.
Explanation: At least one invalid character was detected in the specified suboption.
Programmer Response: If you do not want to accept the default, specify valid characters.
System Action: The default value will be used.
IWZ178S Argument-1 for function function-name was less than or equal to decimal-
value.
IWZ181I An invalid character was found in the numeric string string of the run-time
option option-name. The default will be used.
IWZ182I The number number of the run-time option option-name exceeded the range
of min-range to max-range. The default will be used.
Explanation: The run unit termination exit routine returned to the invoker of the routine (the func-
tion specified in function_code).
Programmer Response: Rewrite the function so that the run unit termination exit routine does a
longjump or exit() instead of return to the function.
System Action: The application was terminated.
IWZ200S Error detected during I/O operation for file file-name. File status is: file-status.
Explanation: An error was detected during a file I/O operation. No file status was specified for
the file and no applicable error declarative is in effect for the file.
Programmer Response: Correct the condition described in this message. You can specify the
FILE STATUS clause for the file if you want to detect the error and take appropriate actions within
your source program.
System Action: The application was terminated.
IWZ200S STOP or ACCEPT failed with an I/O error, error-code. The run unit is termi-
nated.
Explanation: An error was detected during a file I/O operation for a VSAM file. No file status
was specified for the file and no applicable error declarative is in effect for the file.
Programmer Response: Correct the condition described in this message. For details, see the
SMARTdata Utilities VSAM manual for your platform:
For OS/2: VSAM in a Distributed Environment
For Windows: VSAM API Reference
For AIX: VSAM in a Distributed Environment
System Action: The application was terminated.
Explanation: References to DBCS data was made with a non-DBCS code page in effect.
Programmer Response: For DBCS data, specify a valid DBCS code page. Valid DBCS code
pages are:
Note: The code pages listed above might not be supported for a specific version or release of
that platform. For additional information, see “Locales and Code Sets Supported on AIX” on
page 408.
System Action: No system action was taken.
IWZ204W An error occurred during conversion from ASCII DBCS to EBCDIC DBCS.
Explanation: A Kanji or DBCS class test failed due to an error detected during the ASCII char-
acter string EBCDIC string conversion.
Programmer Response: Verify that the locale in effect is consistent with the ASCII character
string being tested. No action is likely to be required if the locale setting is correct. The class test
is likely to indicate the string to be non-Kanji or non-DBCS correctly.
System Action: No system action was taken.
IWZ230W The conversion table for the current codeset, ASCII codeset-id, to the
EBCDIC codeset, EBCDIC codeset-id, is not available. The default ASCII to
EBCDIC conversion table will be used.
Explanation: The application has a module which was compiled with the CHAR(EBCDIC) com-
piler option. At run-time a translation table will be built to handle the conversion from the current
ASCII code page to an EBCDIC code page specified by the EBCDIC_CODEPAGE environment
variable. This error occurred because either a conversion table is not available for the specified
code pages, or the specification of the EBCDIC_CODE page is invalid. Execution will continue
with a default conversion table based on ASCII code page IBM-850 and EBCDIC code page
IBM-037.
Programmer Response: Verify that the EBCDIC_CODEPAGE environment variable has a valid
value (see “Locales and Code Sets Supported on AIX” on page 408).
If EBCDIC_CODEPAGE is not set, the default value, IBM-037, will be used. This is the default
code page used by IBM COBOL for OS/390 & VM.
System Action: No system action was taken.
IWZ230W The EBCDIC codepage specified, EBCDIC codepage, is not consistent with
the locale locale, but will be used as requested.
Explanation: The application has a module which was compiled with the CHAR(EBCDIC) com-
piler option. This error occurred because the code page specified is not the same language as the
current locale.
Programmer Response: Verify that the EBCDIC_CODEPAGE environment variable is valid for
this locale (see “Locales and Code Sets Supported on AIX” on page 408).
System Action: No system action was taken.
IWZ230W The EBCDIC codepage specified, EBCDIC codepage, is not supported. The
default EBCDIC codepage, EBCDIC codepage, will be used.
Explanation: The application has a module which was compiled with the CHAR(EBCDIC) com-
piler option. This error occurred because the specification of the EBCDIC_CODE page is invalid.
Execution will continue with the default host code page that corresponds to the current locale.
Programmer Response: Verify that the EBCDIC_CODEPAGE environment variable has a valid
value (see “Locales and Code Sets Supported on AIX” on page 408).
System Action: No system action was taken.
Explanation: The current system installation does not include the translation table for the default
ASCII and EBCDIC code pages.
Programmer Response: Reinstall the compiler and run time. If the problem still persists, call
your IBM representative.
System Action: The application was terminated.
Explanation: The ASCII to EBCDIC conversion table has been opened, but the conversion has
failed.
Programmer Response: Retry the execution from a new window.
System Action: The application was terminated.
Explanation: A query of the execution environment failed to identify a valid locale setting. The
current locale needs to be established to access appropriate message files and set the collating
order. It is also used by the date/time services and for EBCDIC character support.
Programmer Response: Check the settings for the following environment variables:
LOCPATH
– Not used on AIX.
– On OS/2 and Windows, this environment variable should include the IBMCOBOL\LOCALE
directory
LANG
– On OS/2, this environment variable should be set to the filename (without extension) of
one of the DLLs located in the IBM\LOCALE directory. The default value is en_US.
– On Windows this should be set to the name of one of the directories located in the
IBMCOBW\LOCALE directory. The default value is en_US.
– On AIX this should be set to a locale which has been installed on your machine. Type
"locale -a" to get a list of the valid values. The default value is en_US.
System Action: The application was terminated.
| IWZ240S The base year for program program-name was outside the valid range of
| 1900 through 1999. The sliding window value window-value resulted in a
| base year of base-year.
| Explanation: When the 100-year window was computed using the current year and the sliding
| window value specified with the YEARWINDOW compiler option, the base year of the 100-year
| window was outside the valid range of 1900 through 1999.
| For example, if a COBOL program had been compiled with YEARWINDOW(-99) and the COBOL
| program was run in the year 1998 this message would occur because the base year of the
| 100-year window would be 1899 (1998 - 99).
| Programmer Response: Examine the application design to determine if it will support a change
| to the YEARWINDOW option value. If the application can run with a change to the
| YEARWINDOW option value, then compile the program with an appropriate YEARWINDOW option
| value. If the application cannot run with a change to the YEARWINDOW option value, then
| convert all date fields to expanded dates and compile the program with NODATEPROC.
| System Action: The application was terminated.
| IWZ241S The current year was outside the 100-year window, year-start through
| year-end, for program program-name.
| Explanation: The current year was outside the 100-year fixed window specified by the
| YEARWINDOW compiler option value.
| For example, if a COBOL program is compiled with YEARWINDOW(1920), the 100-year window
| for the program is 1920 through 2019. When the program is run in the year 2020, this error
| message would occur since the current year is not within the 100-year window.
| Programmer Response: Examine the application design to determine if it will support a change
| to the YEARWINDOW option value. If the application can run with a change to the
| YEARWINDOW option value, then compile the program with an appropriate YEARWINDOW option
| value. If the application cannot run with a change to the YEARWINDOW option value, then
| convert all date fields to expanded dates and compile the program with NODATEPROC.
| System Action: The application was terminated.
Explanation: There was not enough free storage available to satisfy a get storage or reallocate
request. This message indicates that storage management could not obtain sufficient storage from
the operating system.
Programmer Response: Ensure that you have sufficient storage available to run your applica-
tion.
System Action: No storage is allocated.
Symbolic Feedback Code: CEE0PD
Explanation: The run-time library requested virtual memory space and the operating system
denied the request.
Programmer Response: Your program uses a large amount of virtual memory and it ran out of
space. The problem is usually not due to a particular statement, but is associated with the
program as a whole. Look at your use of OCCURS clauses and reduce the size of your tables.
System Action: No system action was taken.
Explanation: The run-time library requested virtual memory space and the operating system
denied the request.
Programmer Response: Your program uses a large amount of virtual memory and it ran out of
space. The problem is usually not due to a particular statement, but is associated with the
program as a whole. Look at your use of OCCURS clauses and reduce the size of your tables.
System Action: No system action was taken.
Explanation: The run-time library cannot find either the message catalog or a particular message
in the message catalog.
Programmer Response: Check that the COBOL library and messages were correctly installed
and that NLSPATH is specified correctly.
System Action: No system action was taken.
Explanation: The operating system has detected an illegal action, such as an attempt to store
into a protected area of memory or the operating system has detected that you pressed the inter-
rupt key (typically the Control-C key, but it can be reconfigured).
Programmer Response: If the signal was due to an illegal action, run the program under the
debugger and it will give you more precise information as to where the error occurred. An
example of this type of error is a pointer with an illegal value.
System Action: The application was terminated.
Explanation: A call to CEEUTC or CEEGMT failed because the system clock was in an invalid
state. The current time could not be determined.
Programmer Response: Notify systems support personnel that the system clock is in an invalid
state.
System Action: All output values are set to 0.
Symbolic Feedback Code: CEE2E6
IWZ2503S The offset from UTC/GMT to local time was not available from the system.
Explanation: A call to CEEGMTO failed because either (1) the current operating system could
not be determined, or (2) the time zone field in the operating system control block appears to
contain invalid data.
Programmer Response: Notify systems support personnel that the local time offset stored in the
operating system appears to contain invalid data.
System Action: All output values are set to 0.
Symbolic Feedback Code: CEE2E7
IWZ2505S The input_seconds value in a call to CEEDATM or CEESECI was not within
the supported range.
Explanation: The input_seconds value passed in a call to CEEDATM or CEESECI was not a
floating-point number between 86,400.0 and 265,621,679,999.999 The input parameter should rep-
resent the number of seconds elapsed since 00:00:00 on 14 October 1582, with 00:00:00.000 15
October 1582 being the first supported date/time, and 23:59:59.999 31 December 9999 being the
last supported date/time.
Programmer Response: Verify that input parameter contains a floating-point value between
86,400.0 and 265,621,679,999.999.
System Action: For CEEDATM, the output value is set to blanks. For CEESECI, all output
parameters are set to 0.
Symbolic Feedback Code: CEE2E9
Explanation: In a CEEDATM call, the picture string indicates that the input value is to be con-
verted to a Japanese or Republic of China Era; however the input value that was specified lies
outside the range of supported eras.
Programmer Response: Verify that the input value contains a valid number-of-seconds value
within the range of supported eras.
System Action: The output value is set to blanks.
IWZ2507S Insufficient data was passed to CEEDAYS or CEESECS. The Lilian value
was not calculated.
Explanation: The picture string passed in a CEEDAYS or CEESECS call did not contain enough
information. For example, it is an error to use the picture string ‘MM/DD’ (month and day only) in
a call to CEEDAYS or CEESECS, because the year value is missing. The minimum information
required to calculate a Lilian value is either (1) month, day and year, or (2) year and Julian day.
Programmer Response: Verify that the picture string specified in a call to CEEDAYS or
CEESECS specifies, as a minimum, the location in the input string of either (1) the year, month,
and day, or (2) the year and Julian day.
System Action: The output value is set to 0.
Symbolic Feedback Code: CEE2EB
Explanation: In a CEEDAYS or CEESECS call, the value in the DD or DDD field is not valid for
the given year and/or month. For example, ‘MM/DD/YY’ with ‘02/29/90’, or ‘YYYY.DDD’ with
‘1990.366’ are invalid because 1990 is not a leap year. This code may also be returned for any
non-existent date value such as June 31st, January 0.
Programmer Response: Verify that the format of the input data matches the picture string spec-
ification and that input data contains a valid date.
System Action: The output value is set to 0.
Symbolic Feedback Code: CEE2EC
Explanation: The value in the <JJJJ>, <CCCC>, or <CCCCCCCC> field passed in a call to
CEEDAYS or CEESECS does not contain a supported Japanese or Republic of China Era name.
Programmer Response: Verify that the format of the input data matches the picture string spec-
ification and that the spelling of the Japanese or ROC Era name is correct. Note that the era
name must be a proper DBCS string where the '<' position must contain the first byte of the era
name.
System Action: The output value is set to 0.
IWZ2510S The hours value in a call to CEEISEC or CEESECS was not recognized.
Explanation: (1) In a CEEISEC call, the hours parameter did not contain a number between 0
and 23, or (2) in a CEESECS call, the value in the HH (hours) field does not contain a number
between 0 and 23, or the “AP” (a.m./p.m.) field is present and the HH field does not contain a
number between 1 and 12.
Programmer Response: For CEEISEC, verify that the hours parameter contains an integer
between 0 and 23. For CEESECS, verify that the format of the input data matches the picture
string specification, and that the hours field contains a value between 0 and 23, (or 1 and 12 if the
“AP” field is used).
IWZ2511S The day parameter passed in a CEEISEC call was invalid for year and
month specified.
Explanation: The day parameter passed in a CEEISEC call did not contain a valid day number.
The combination of year, month, and day formed an invalid date value. Examples: year=1990,
month=2, day=29; or month=6, day=31; or day=0.
Programmer Response: Verify that the day parameter contains an integer between 1 and 31,
and that the combination of year, month, and day represents a valid date.
System Action: The output value is set to 0.
Symbolic Feedback Code: CEE2EF
IWZ2512S The Lilian date value passed in a call to CEEDATE or CEEDYWK was not
within the supported range.
Explanation: The Lilian day number passed in a call to CEEDATE or CEEDYWK was not a
number between 1 and 3,074,324.
Programmer Response: Verify that the input parameter contains an integer between 1 and
3,074,324.
System Action: The output value is set to blanks.
Symbolic Feedback Code: CEE2EG
IWZ2513S The input date passed in a CEEISEC, CEEDAYS, or CEESECS call was not
within the supported range.
Explanation: The input date passed in a CEEISEC, CEEDAYS, or CEESECS call was earlier
than 15 October 1582, or later than 31 December 9999.
Programmer Response: For CEEISEC, verify that the year, month, and day parameters form a
date greater than or equal to 15 October 1582. For CEEDAYS and CEESECS, verify that the
format of the input date matches the picture string specification, and that the input date is within
the supported range.
System Action: The output value is set to 0.
Symbolic Feedback Code: CEE2EH
IWZ2514S The year value passed in a CEEISEC call was not within the supported
range.
Explanation: The year parameter passed in a CEEISEC call did not contain a number between
1582 and 9999.
Programmer Response: Verify that the year parameter contains valid data, and that the year
parameter includes the century, for example, specify year 1990, not year 90.
System Action: The output value is set to 0.
Symbolic Feedback Code: CEE2EI
Explanation: In a CEEISEC call, the milliseconds parameter (input_milliseconds) did not contain
a number between 0 and 999.
Programmer Response: Verify that the milliseconds parameter contains an integer between 0
and 999.
System Action: The output value is set to 0.
Symbolic Feedback Code: CEE2EJ
Explanation: (1) In a CEEISEC call, the minutes parameter (input_minutes) did not contain a
number between 0 and 59, or (2) in a CEESECS call, the value in the MI (minutes) field did not
contain a number between 0 and 59.
Programmer Response: For CEEISEC, verify that the minutes parameter contains an integer
between 0 and 59. For CEESECS, verify that the format of the input data matches the picture
string specification, and that the minutes field contains a number between 0 and 59.
System Action: The output value is set to 0.
Symbolic Feedback Code: CEE2EK
Explanation: (1) In a CEEISEC call, the month parameter (input_month) did not contain a
number between 1 and 12, or (2) in a CEEDAYS or CEESECS call, the value in the MM field did
not contain a number between 1 and 12, or the value in the MMM, MMMM, etc. field did not
contain a correctly spelled month name or month abbreviation in the currently active National Lan-
guage.
Programmer Response: For CEEISEC, verify that the month parameter contains an integer
between 1 and 12. For CEEDAYS and CEESECS, verify that the format of the input data matches
the picture string specification. For the MM field, verify that the input value is between 1 and 12.
For spelled-out month names (MMM, MMMM, etc.), verify that the spelling or abbreviation of the
month name is correct in the currently active National Language.
System Action: The output value is set to 0.
Symbolic Feedback Code: CEE2EL
Explanation: The picture string supplied in a call to one of the date/time services was invalid.
Only one era character string can be specified.
Programmer Response: Verify that the picture string contains valid data. If the picture string
contains more than one era descriptor, such as both Japanese (<JJJJ>) and Republic of China
(<CCCC>) being specified, then change the picture string to use only one era.
System Action: The output value is set to 0.
Symbolic Feedback Code: CEE2EM
Explanation: (1) In a CEEISEC call, the seconds parameter (input_seconds) did not contain a
number between 0 and 59, or (2) in a CEESECS call, the value in the SS (seconds) field did not
contain a number between 0 and 59.
Programmer Response: For CEEISEC, verify that the seconds parameter contains an integer
between 0 and 59. For CEESECS, verify that the format of the input data matches the picture
string specification, and that the seconds field contains a number between 0 and 59.
System Action: The output value is set to 0.
Symbolic Feedback Code: CEE2EN
IWZ2520S CEEDAYS detected non-numeric data in a numeric field, or the date string
did not match the picture string.
Explanation: The input value passed in a CEEDAYS call did not appear to be in the format
described by the picture specification, for example, non-numeric characters appear where only
numeric characters are expected.
Programmer Response: Verify that the format of the input data matches the picture string spec-
ification and that numeric fields contain only numeric data.
System Action: The output value is set to 0.
Symbolic Feedback Code: CEE2EO
Explanation: In a CEEDAYS or CEESECS call, if the YY or ZYY picture token is specified, and if
the picture string contains one of the era tokens such as <CCCC> or <JJJJ>, then the year value
must be greater than or equal to 1 and must be a valid year value for the era. In this context, the
YY or ZYY field means year within Era.
Programmer Response: Verify that the format of the input data matches the picture string spec-
ification and that the input data is valid.
System Action: The output value is set to 0.
Explanation: In a CEEDATE call, the picture string indicates that the Lilian date is to be con-
verted to a Japanese or Republic of China Era, but the Lilian date lies outside the range of sup-
ported eras.
Programmer Response: Verify that the input value contains a valid Lilian day number within the
range of supported eras.
System Action: The output value is set to blanks.
Explanation: The input value passed in a CEESECS call did not appear to be in the format
described by the picture specification. For example, non-numeric characters appear where only
numeric characters are expected, or the a.m./p.m. field (AP, A.P., etc.) did not contain the strings
‘AM’ or ‘PM’.
Programmer Response: Verify that the format of the input data matches the picture string spec-
ification and that numeric fields contain only numeric data.
System Action: The output value is set to 0.
Symbolic Feedback Code: CEE2ET
Explanation: In a CEEDATE call, the output string was not large enough to contain the formatted
date value.
Programmer Response: Verify that the output string variable is large enough to contain the
entire formatted date. Ensure that the output parameter is at least as long as the picture string
parameter.
System Action: The output value is truncated to the length of the output parameter.
Symbolic Feedback Code: CEE2EU
Explanation: In a CEEDATM call, the output string was not large enough to contain the for-
matted timestamp value.
Programmer Response: Verify that the output string variable is large enough to contain the
entire formatted timestamp. Ensure that the output parameter is at least as long as the picture
string parameter.
System Action: The output value is truncated to the length of the output parameter.
Symbolic Feedback Code: CEE2EV
IWZ2531S The local time was not available from the system.
Explanation: A call to CEELOCT failed because the system clock was in an invalid state. The
current time cannot be determined.
Programmer Response: Notify systems support personnel that the system clock is in an invalid
state.
System Action: All output values are set to 0.
Symbolic Feedback Code: CEE2F3
IWZ2533S The value passed to CEESCEN was not between 0 and 100.
Explanation: The century_start value passed in a CEESCEN call was not between 0 and 100,
inclusive.
Programmer Response: Ensure that the input parameter is within range.
System Action: No system action is taken; the 100-year window assumed for all 2-digit years is
unchanged.
Symbolic Feedback Code: CEE2F5
IWZ2534W Insufficient field width was specified for a month or weekday name in a call
to CEEDATE or CEEDATM. Output set to blanks.
Explanation: The CEEDATE or CEEDATM callable services issues this message whenever the
picture string contained MMM, MMMMMZ, WWW, Wwww, etc., requesting a spelled out month
name or weekday name, and the month name currently being formatted contained more charac-
ters than can fit in the indicated field.
Programmer Response: Increase the field width by specifying enough Ms or Ws to contain the
longest month or weekday name being formatted.
System Action: The month name and weekday name fields that are of insufficient width are set
to blanks. The rest of the output string is unaffected. Processing continues.
Symbolic Feedback Code: CEE2F6
Debug Tool User's Guide and Reference, DATABASE 2 AIX/6000 Command Reference,
SC09-2137 SC09-1575
IBM is grateful to the American National Standards Insti- * alphanumeric function. A function whose value is
tute (ANSI) for permission to reprint its definitions from composed of a string of one or more characters from the
the following publications: computer's character set.
American National Standard Programming Lan-
* alternate record key. A key, other than the prime
guage COBOL, ANSI X3.23-1985 (Copyright 1985
record key, whose contents identify a record within an
American National Standards Institute, Inc.), which
indexed file.
was prepared by Technical Committee X3J4, which
had the task of revising American National Standard ANSI (American National Standards Institute). An
COBOL, X3.23-1974. organization consisting of producers, consumers, and
American National Dictionary for Information Proc- general interest groups, that establishes the procedures
essing Systems (Copyright 1982 by the Computer by which accredited organizations create and maintain
and Business Equipment Manufacturers Associ- voluntary industry standards in the United States.
ation).
* argument. An identifier, a literal, an arithmetic
American National Standard definitions are preceded by expression, or a function-identifier that specifies a value
an asterisk (*). to be used in the evaluation of a function.
* access mode. The manner in which records are to * arithmetic operator. A single character, or a fixed
be operated upon within a file. two-character combination that belongs to the following
set:
* actual decimal point. The physical representation, Character Meaning
using the decimal point characters period (.) or comma + addition
(,), of the decimal point position in a data item. - subtraction
* multiplication
* alphabet-name. A user-defined word, in the
/ division
SPECIAL-NAMES paragraph of the ENVIRONMENT
** exponentiation
DIVISION, that assigns a name to a specific character
set and/or collating sequence. * arithmetic statement. A statement that causes an
arithmetic operation to be executed. The arithmetic
* alphabetic character. A letter or a space character.
statements are the ADD, COMPUTE, DIVIDE, MUL-
TIPLY, and SUBTRACT statements.
* alphanumeric character. Any character in the
computer’s character set.
array. In Language Environment, an aggregate con-
sisting of data objects, each of which may be uniquely
* ascending key. A key upon the values of which data binary search. A dichotomizing search in which, at
is ordered, starting with the lowest value of the key up to each step of the search, the set of data elements is
the highest value of the key, in accordance with the divided by two; some appropriate action is taken in the
rules for comparing data items. case of an odd number.
ASCII. American National Standard Code for Informa- * block. A physical unit of data that is normally com-
tion Interchange. The standard code, using a coded posed of one or more logical records. For mass storage
character set consisting of 7-bit coded characters (8 bits files, a block may contain a portion of a logical record.
including parity check), used for information interchange The size of a block has no direct relationship to the size
between data processing systems, data communication of the file within which the block is contained or to the
systems, and associated equipment. The ASCII set con- size of the logical record(s) that are either contained
sists of control characters and graphic characters. within the block or that overlap the block. The term is
synonymous with physical record.
Extension: IBM has defined an extension to ASCII
code (characters 128-255).
breakpoint. A place in a computer program, usually
specified by an instruction, where its execution may be
assignment-name. A name that identifies the organiza-
interrupted by external intervention or by a monitor
tion of a COBOL file and the name by which it is known
program.
to the system.
Btrieve. A key-indexed record management system
* assumed decimal point. A decimal point position
that allows applications to manage records by key value,
that does not involve the existence of an actual char-
sequential access method, or random access method.
acter in a data item. The assumed decimal point has
IBM COBOL supports COBOL sequential and indexed
logical meaning with no physical representation.
file I-O language through Btrieve.
* AT END condition. A condition caused:
buffer. A portion of storage used to hold input or output
1. During the execution of a READ statement for a data temporarily.
sequentially accessed file, when no next logical
record exists in the file, or when the number of sig- built-in function. See “intrinsic function.”
nificant digits in the relative record number is larger
than the size of the relative key data item, or when byte. A string consisting of a certain number of bits,
an optional input file is not present. usually eight, treated as a unit, and representing a char-
acter.
2. During the execution of a RETURN statement, when
no next logical record exists for the associated sort
or merge file.
C
3. During the execution of a SEARCH statement, when
the search operation terminates without satisfying callable services. In Language Environment, a set of
the condition specified in any of the associated services that can be invoked by a COBOL program
WHEN phrases. using the conventional Language Environment-defined
call interface, and usable by all programs sharing the
Language Environment conventions.
B
called program. A program that is the object of a
big-endian. Default format used by the mainframe and CALL statement.
the AIX workstation to store binary data. In this format,
the least significant digit is on the highest address. * calling program. A program that executes a CALL to
Compare with “little-endian.” another program.
binary item. A numeric data item represented in binary case structure. A program processing logic in which a
notation (on the base 2 numbering system). Binary series of conditions is tested in order to make a choice
items have a decimal equivalent consisting of the between a number of resulting actions.
Glossary 565
most character position of the print line and extending to | – Another windowed date field with date format
the rightmost position of the print line. | YYXXX
| – An expanded date field with date format
* combined condition. A condition that is the result of | YYYYXXX
connecting two or more conditions with the AND or the
OR logical operator. * compile. (1) To translate a program expressed in a
high-level language into a program expressed in an
* comment-entry. An entry in the IDENTIFICATION intermediate language, assembly language, or a com-
DIVISION that may be any combination of characters puter language. (2) To prepare a machine language
from the computer’s character set. program from a computer program written in another
programming language by making use of the overall
* comment line. A source program line represented by logic structure of the program, or generating more than
an asterisk (*) in the indicator area of the line and any one computer instruction for each symbolic statement, or
characters from the computer’s character set in area A both, as well as performing the function of an assembler.
and area B of that line. The comment line serves only
for documentation in a program. A special form of * compile time. The time at which a COBOL source
comment line represented by a slant (/) in the indicator program is translated, by a COBOL compiler, to a
area of the line and any characters from the computer’s COBOL object program.
character set in area A and area B of that line causes
page ejection prior to printing the comment. compiler. A program that translates a program written
in a higher level language into a machine language
* common program. A program which, despite being object program.
directly contained within another program, may be called
from any program directly or indirectly contained in that compiler directing statement. A statement, beginning
other program. with a compiler directing verb, that causes the compiler
to take a specific action during compilation.
| compatible dates. The meaning of the term “compat-
| ible,” when applied to date fields, depends on the compiler directing statement. A statement that speci-
| COBOL division in which the usage occurs: fies actions to be taken by the compiler during proc-
essing of a COBOL source program. Compiler
| Data Division
directives are contained in the COBOL source program.
| Two date fields are compatible if they have identical Thus, you can specify different suboptions of the direc-
| USAGE and meet at least one of the following tive within the source program by using multiple compiler
| conditions: directive statements in the program.
| – They have the same date format.
* complex condition. A condition in which one or more
| – Both are windowed date fields, where one con- logical operators act upon one or more conditions. (See
| sists only of a windowed year, date format YY. also “negated simple condition,” “combined condition,”
| – Both are expanded date fields, where one con- and “negated combined condition.”)
| sists only of an expanded year, date format
* computer-name. A system-name that identifies the
| YYYY.
computer upon which the program is to be compiled or
| – One has date format YYXXXX, the other, run.
| YYXX.
condition. An exception that has been enabled, or
| – One has date format YYYYXXXX, the other,
recognized, by Language Environment and thus is eli-
| YYYYXX.
gible to activate user and language condition handlers.
| Procedure Division Any alteration to the normal programmed flow of an
| Two date fields are compatible if they have the application. Conditions can be detected by the
| same date format except for the year part, which hardware/operating system and results in an interrupt.
| may be windowed or expanded. For example, a They can also be detected by language-specific gener-
| windowed date field with date format YYXXX is ated code or language library code.
| compatible with:
* condition. A status of a program at run time for
which a truth value can be determined. Where the term
* condition-name condition. The proposition, for * current record. In file processing, the record that is
which a truth value can be determined, that the value of available in the record area associated with a file.
a conditional variable is a member of the set of values
attributed to a condition-name associated with the condi- * current volume pointer. A conceptual entity that
tional variable. points to the current volume of a sequential file.
* contiguous items. Items that are described by con- * data description entry . An entry in the DATA DIVI-
secutive entries in the Data Division, and that bear a SION of a COBOL program that is composed of a level-
definite hierarchic relationship to each other. number followed by a data-name, if required, and then
followed by a set of data clauses, as required.
Glossary 567
DATA DIVISION. One of the four main components of * debugging line. A debugging line is any line with a
a COBOL program, class definition, or method definition. ‘D’ in the indicator area of the line.
The DATA DIVISION describes the data to be processed
by the object program, class, or method: files to be * debugging section. A section that contains a USE
used and the records contained within them; internal FOR DEBUGGING statement.
working-storage records that will be needed; data to be
made available in more than one program in the COBOL * declarative sentence. A compiler directing sentence
run unit. (Note, the Class DATA DIVISION contains only consisting of a single USE statement terminated by the
the WORKING-STORAGE SECTION.) separator period.
* data item. A unit of data (excluding literals) defined * declaratives. A set of one or more special purpose
by a COBOL program or by the rules for function evalu- sections, written at the beginning of the Procedure Divi-
ation. sion, the first of which is preceded by the key word
DECLARATIVES and the last of which is followed by the
* data-name. A user-defined word that names a data key words END DECLARATIVES. A declarative is com-
item described in a data description entry. When used posed of a section header, followed by a USE compiler
in the general formats, ‘data-name’ represents a word directing sentence, followed by a set of zero, one, or
that must not be reference-modified, subscripted or qual- more associated paragraphs.
ified unless specifically permitted by the rules for the
format. * de-edit. The logical removal of all editing characters
from a numeric edited data item in order to determine
| date field. Any of the following: that item's unedited numeric value.
| A data item whose data description entry includes a * delimited scope statement. Any statement that
| DATE FORMAT clause. includes its explicit scope terminator.
| A value returned by one of the following intrinsic
| functions: * delimiter. A character or a sequence of contiguous
characters that identify the end of a string of characters
| DATE-OF-INTEGER and separate that string of characters from the following
| DATE-TO-YYYYMMDD string of characters. A delimiter is not part of the string
| DATEVAL of characters that it delimits.
| DAY-OF-INTEGER
| DAY-TO-YYYYDDD * descending key. A key upon the values of which
| YEAR-TO-YYYY data is ordered starting with the highest value of key
| YEARWINDOW down to the lowest value of key, in accordance with the
| The conceptual data items DATE, DATE rules for comparing data items.
| YYYYMMDD, DAY, and DAY YYYYDDD in the
| Format 2 ACCEPT statement. digit. Any of the numerals from 0 through 9. In
COBOL, the term is not used in reference to any other
| The result of certain arithmetic operations. symbol.
| The term date field refers to both “expanded date field”
| and “windowed date field.” See also “non-date.” * digit position. The amount of physical storage
required to store a single digit. This amount may vary
| date format. The date pattern of a date field, specified depending on the usage specified in the data description
| either: entry that defines the data item.
| Explicitly, by the DATE FORMAT clause or * direct access. The facility to obtain data from storage
| DATEVAL intrinsic function devices or to enter data into a storage device in such a
| or way that the process depends only on the location of
that data and not on a reference to data previously
| Implicitly, by statements and intrinsic functions that accessed.
| return date fields.
* division. A collection of zero, one or more sections or
DBCS (Double-Byte Character Set). See “Double- paragraphs, called the division body, that are formed
Byte Character Set (DBCS).” and combined in accordance with a specific set of rules.
Glossary 569
* end of Procedure Division. The physical position of exponent. A number, indicating the power to which
a COBOL source program after which no further proce- another number (the base) is to be raised. Positive
dures appear. exponents denote multiplication, negative exponents
denote division, fractional exponents denote a root of a
* end program header. A combination of words, fol- quantity. In COBOL, an exponential expression is indi-
lowed by a separator period, that indicates the end of a cated with the symbol ‘**’ followed by the exponent.
COBOL source program. The end program header is:
END PROGRAM program-name. * expression. An arithmetic or conditional expression.
* entry. Any descriptive set of consecutive clauses ter- * extend mode. The state of a file after execution of an
minated by a separator period and written in the IDEN- OPEN statement, with the EXTEND phrase specified for
TIFICATION DIVISION, ENVIRONMENT DIVISION, or that file, and before the execution of a CLOSE state-
DATA DIVISION of a COBOL program. ment, without the REEL or UNIT phrase for that file.
* environment clause. A clause that appears as part extensions. Certain COBOL syntax and semantics
of an ENVIRONMENT DIVISION entry. supported by IBM compilers in addition to those
described in ANSI Standard.
ENVIRONMENT DIVISION. One of the four main com-
ponent parts of a COBOL program, class definition, or * external data. The data described in a program as
method definition. The ENVIRONMENT DIVISION external data items and external file connectors.
describes the computers upon which the source program
* external data item. A data item which is described as
is compiled and those on which the object program is
part of an external record in one or more programs of a
executed, and provides a linkage between the logical
run unit and which itself may be referenced from any
concept of files and their records, and the physical
program in which it is described.
aspects of the devices on which files are stored.
* external data record. A logical record which is
environment-name. A name, specified by IBM, that
described in one or more programs of a run unit and
identifies system logical units, printer and card punch
whose constituent data items may be referenced from
control characters, report codes, and/or program
any program in which they are described.
switches. When an environment-name is associated
with a mnemonic-name in the ENVIRONMENT DIVI-
external decimal item. A format for representing
SION, the mnemonic-name may then be substituted in
numbers in which the digit is contained in bits 4 through
any format in which such substitution is valid.
7 and the sign is contained in bits 0 through 3 of the
rightmost byte. Bits 0 through 3 of all other bytes
environment variable. Any of a number of variables
contain 1’s (hex F). For example, the decimal value of
that describe the way an operating system is going to
+123 is represented as 1111 0001 1111 0010 1111
run and the devices it is going to recognize.
0011. (Also know as “zoned decimal item.”)
execution time. See “run time.”
* external file connector. A file connector which is
execution-time environment. See “run-time environ- accessible to one or more object programs in the run
ment.” unit.
| expanded date field. A date field containing an external floating-point item. A format for representing
| expanded (4-digit) year. See also “date field” and numbers in which a real number is represented by a pair
| “expanded year.” of distinct numerals. In a floating-point representation,
the real number is the product of the fixed-point part (the
| expanded year. Four digits representing a year, first numeral), and a value obtained by raising the
| including the century (for example, 1998). Appears in implicit floating-point base to a power denoted by the
| expanded date fields. Compare with “windowed year.” exponent (the second numeral).
For example, a floating-point representation of the
* explicit scope terminator. A reserved word that ter- number 0.0001234 is: 0.1234 -3, where 0.1234 is the
minates the scope of a particular Procedure Division mantissa and -3 is the exponent.
statement.
* file attribute conflict condition. An unsuccessful * fixed file attributes. Information about a file which is
attempt has been made to execute an input-output oper- established when a file is created and cannot subse-
ation on a file and the file attributes, as specified for that quently be changed during the existence of the file.
file in the program, do not match the fixed attributes for These attributes include the organization of the file
that file. (sequential, relative, or indexed), the prime record key,
the alternate record keys, the code set, the minimum
* file clause. A clause that appears as part of any of and maximum record size, the record type (fixed or vari-
the following DATA DIVISION entries: file description able), the collating sequence of the keys for indexed
entry (FD entry) and sort-merge file description entry files, the blocking factor, the padding character, and the
(SD entry). record delimiter.
* file connector. A storage area which contains infor- * fixed length record. A record associated with a file
mation about a file and is used as the linkage between a whose file description or sort-merge description entry
file-name and a physical file and between a file-name requires that all records contain the same number of
and its associated record area. character positions.
File-Control. The name of an ENVIRONMENT DIVI- fixed-point number. A numeric data item defined with
SION paragraph in which the data files for a given a PICTURE clause that specifies the location of an
source program are declared. optional sign, the number of digits it contains, and the
location of an optional decimal point. The format may
* file control entry. A SELECT clause and all its sub- be either binary, packed decimal, or external decimal.
ordinate clauses which declare the relevant physical
attributes of a file. floating-point number. A numeric data item containing
a fraction and an exponent. Its value is obtained by
* file description entry. An entry in the File Section of multiplying the fraction by the base of the numeric data
the DATA DIVISION that is composed of the level indi- item raised to the power specified by the exponent.
cator FD, followed by a file-name, and then followed by
a set of file clauses as required. * format. A specific arrangement of a set of data.
* file-name. A user-defined word that names a file con- * function. A temporary data item whose value is
nector described in a file description entry or a sort- determined at the time the function is referenced during
merge file description entry within the File Section of the the execution of a statement.
DATA DIVISION.
* function-identifier. A syntactically correct combina-
* file organization. The permanent logical file structure tion of character-strings and separators that references a
established at the time that a file is created. function. The data item represented by a function is
uniquely identified by a function-name with its argu-
*file position indicator. A conceptual entity that con- ments, if any. A function-identifier may include a
tains the value of the current key within the key of refer- reference-modifier. A function-identifier that references
ence for an indexed file, or the record number of the an alphanumeric function may be specified anywhere in
current record for a sequential file, or the relative record
Glossary 571
the general formats that an identifier may be specified, IGZCBSN. The COBOL/370 Release 1 bootstrap
subject to certain restrictions. A function-identifier that routine. It must be link-edited with any module that con-
references an integer or numeric function may be refer- tains a COBOL/370 Release 1 program.
enced anywhere in the general formats that an arith-
metic expression may be specified. IGZCBSO. The COBOL for MVS & VM Release 2 and
IBM COBOL for OS/390 & VM bootstrap routine. It must
function-name. A word that names the mechanism be link-edited with any module that contains a COBOL
whose invocation, along with required arguments, deter- for MVS & VM Release 2 or IBM COBOL for OS/390 &
mines the value of a function. VM program.
inline. In a program, instructions that are executed integer function. A function whose category is numeric
sequentially, without branching to routines, subroutines, and whose definition does not include any digit positions
or other programs. to the right of the decimal point.
* input file. A file that is opened in the INPUT mode. interface. The information that a client must know to
use a class—the names of its attributes and the signa-
* input mode. The state of a file after execution of an tures of its methods. With direct-to-SOM compilers such
OPEN statement, with the INPUT phrase specified, for as COBOL, the interface to a class may be defined by
that file and before the execution of a CLOSE statement, native language syntax for class definitions. Classes
without the REEL or UNIT phrase for that file. implemented in other languages might have their inter-
faces defined directly in SOM Interface Definition Lan-
* input-output file. A file that is opened in the I-O guage (IDL). The COBOL compiler has a compiler
mode. option, IDLGEN, to automatically generate IDL for a
COBOL class.
* INPUT-OUTPUT SECTION. The section of the ENVI-
RONMENT DIVISION that names the files and the Interface Definition Language (IDL). The formal lan-
external media required by an object program or method guage (independent of any programming language) by
and that provides information required for transmission which the interface for a class of objects is defined in a
and handling of data during execution of the object IDL file, which the SOM compiler then interprets to
program or method definition. create an implementation template file and binding files.
SOM's Interface Definition Language is fully compliant
* Input-Output statement. A statement that causes with standards established by the Object Management
files to be processed by performing operations upon indi- Group's Common Object Request Broker Architecture
vidual records or upon the file as a unit. The input- (CORBA).
output statements are: ACCEPT (with the identifier
phrase), CLOSE, DELETE, DISPLAY, OPEN, READ, interlanguage communication (ILC). The ability of
REWRITE, SET (with the TO ON or TO OFF phrase), routines written in different programming languages to
START, and WRITE. communicate. ILC support allows the application writer
to readily build applications from component routines
* input procedure. A set of statements, to which written in a variety of languages.
control is given during the execution of a SORT state-
ment, for the purpose of controlling the release of speci- intermediate result. An intermediate field containing
fied records to be sorted. the results of a succession of arithmetic operations.
instance data. Data defining the state of an object. * internal data. The data described in a program
The instance data introduced by a class is defined in the excluding all external data items and external file con-
WORKING-STORAGE SECTION of the DATA DIVISION nectors. Items described in the LINKAGE SECTION of
of the class definition. The state of an object also a program are treated as internal data.
includes the state of the instance variables introduced by
base classes that are inherited by the current class. A * internal data item. A data item which is described in
separate copy of the instance data is created for each one program in a run unit. An internal data item may
object instance. have a global name.
* integer. (1) A numeric literal that does not include internal decimal item. A format in which each byte in
any digit positions to the right of the decimal point. a field except the rightmost byte represents two numeric
(2) A numeric data item defined in the DATA DIVISION digits. The rightmost byte contains one digit and the
that does not include any digit positions to the right of sign. For example, the decimal value +123 is repres-
the decimal point. ented as 0001 0010 0011 1111. (Also known as packed
decimal.)
(3) A numeric function whose definition provides that all
digits to the right of the decimal point are zero in the * internal file connector. A file connector which is
accessible to only one object program in the run unit.
Glossary 573
* intra-record data structure. The entire collection of
groups and elementary data items from a logical record K
which is defined by a contiguous subset of the data
description entries which describe that record. These K. When referring to storage capacity, two to the tenth
data description entries include all entries whose level- power; 1024 in decimal notation.
number is greater than the level-number of the first data
description entry describing the intra-record data struc- * key. A data item that identifies the location of a
ture. record, or a set of data items which serve to identify the
ordering of data.
intrinsic function. A pre-defined function, such as a
commonly used arithmetic function, called by a built-in * key of reference. The key, either prime or alternate,
function reference. currently being used to access records within an indexed
file.
* invalid key condition. A condition, at object time,
caused when a specific value of the key associated with * key word. A reserved word or function-name whose
an indexed or relative file is determined to be invalid. presence is required when the format in which the word
appears is used in a source program.
* I-O-CONTROL. The name of an ENVIRONMENT
DIVISION paragraph in which object program require- kilobyte (KB). One kilobyte equals 1024 bytes.
ments for rerun points, sharing of same areas by several
data files, and multiple file storage on a single input-
output device are specified. L
* I-O-CONTROL entry. An entry in the I-O-CONTROL * language-name. A system-name that specifies a par-
paragraph of the ENVIRONMENT DIVISION which con- ticular programming language.
tains clauses that provide information required for the
transmission and handling of data on named files during Language Environment-conforming. A characteristic
the execution of a program. of compiler products (COBOL for OS/390 & VM, COBOL
for MVS & VM, COBOL/370, AD/Cycle C/370, C/C++ for
* I-O-Mode. The state of a file after execution of an MVS and VM, PL/I for MVS and VM) that produce object
OPEN statement, with the I-O phrase specified, for that code conforming to the Language Environment format.
file and before the execution of a CLOSE statement
without the REEL or UNIT phase for that file. last-used state. A program is in last-used state if its
internal values remain the same as when the program
* I-O status. A conceptual entity which contains the was exited (are not reset to their initial values).
two-character value indicating the resulting status of an
input-output operation. This value is made available to * letter. A character belonging to one of the following
the program through the use of the FILE STATUS two sets:
clause in the file control entry for the file. 1. Uppercase letters: A, B, C, D, E, F, G, H, I, J, K, L,
M, N, O, P, Q, R, S, T, U, V, W, X, Y, Z
| ISPF. Interactive System Productivity Facility. An IBM
| software product that provides a menu-driven interface 2. Lowercase letters: a, b, c, d, e, f, g, h, i, j, k, l, m, n,
| to the TSO or VM user. Includes library utilities, a pow- o, p, q, r, s, t, u, v, w, x, y, z
| erful editor, and dialog management.
* level indicator. Two alphabetic characters that iden-
iteration structure. A program processing logic in tify a specific type of file or a position in a hierarchy.
which a series of statements is repeated while a condi- The level indicators in the DATA DIVISION are: CD, FD,
tion is true or until a condition is true. and SD.
* LINAGE-COUNTER. A special register whose value * mass storage file. A collection of records that is
points to the current position within the page body. assigned to a mass storage medium.
LINKAGE SECTION. The section in the DATA DIVI- * megabyte (M). One megabyte equals 1,048,576
SION of the called program that describes data items bytes.
available from the calling program. These data items
may be referred to by both the calling and called * merge file. A collection of records to be merged by a
program. MERGE statement. The merge file is created and can
be used only by the merge function.
literal. A character-string whose value is specified
either by the ordered set of characters comprising the metaclass. A SOM class whose instances are SOM
string, or by the use of a figurative constant. class-objects. The methods defined in metaclasses are
executed without requiring any object instances of the
little-endian. Default format used by the PC to store class to exist, and are frequently used to create
binary data. In this format, the most significant digit is instances of the class.
on the highest address. Compare with “big-endian.”
method. Procedural code that defines one of the oper-
locale. A set of attributes for a program execution envi- ations supported by an object, and that is executed by
ronment indicating culturally sensitive considerations, an INVOKE statement on that object.
such as: character code page, collating sequence,
date/time format, monetary value representation, * Method Definition. The COBOL source unit that
numeric value representation, or language. defines a method.
* LOCAL-STORAGE SECTION. The section of the * method identification entry. An entry in the
DATA DIVISION that defines storage that is allocated METHOD-ID paragraph of the IDENTIFICATION DIVI-
and freed on a per-invocation basis, depending on the SION which contains clauses that specify the method-
value assigned in their VALUE clauses. name and assign selected attributes to the method
definition.
* logical operator. One of the reserved words AND,
OR, or NOT. In the formation of a condition, either * method-name. A user-defined word that identifies a
AND, or OR, or both can be used as logical connectives. method.
NOT can be used for logical negation.
* mnemonic-name. A user-defined word that is associ-
* logical record. The most inclusive data item. The ated in the ENVIRONMENT DIVISION with a specified
level-number for a record is 01. A record may be either implementor-name.
an elementary item or a group of items. The term is
synonymous with record. | MLE. See “millennium language extensions.”
Glossary 575
| millennium language extensions. IBM extension to | non-date. Any of the following:
| COBOL, enabling compiler-assisted date processing for
| A data item whose data description entry does not
| dates containing 2-digit and 4-digit years. Language ele-
| include the DATE FORMAT clause
| ments in support of the millennium language extensions
| are: | A literal
| DATE FORMAT clause in data description entries | A reference-modified date field
| Intrinsic functions: | The result of certain arithmetic operations that may
| include date field operands; for example, the differ-
| DATEVAL
| ence between two compatible dates.
| UNDATE
| YEARWINDOW | The value of a non-date may or may not represent a
| date.
multitasking. Mode of operation that provides for the
concurrent, or interleaved, execution of two or more * non-numeric item. A data item whose description
tasks. When running under the Language Environment permits its content to be composed of any combination
product, multitasking is synonymous with multithreading. of characters taken from the computer’s character set.
Certain categories of non-numeric items may be formed
from more restricted character sets.
N * non-numeric literal. A literal bounded by quotation
name. A word composed of not more than 30 charac- marks. The string of characters may include any char-
ters that defines a COBOL operand. acter in the computer’s character set.
* native character set. The implementor-defined char- null. Figurative constant used to assign the value of an
acter set associated with the computer specified in the invalid address to pointer data items. NULLS can be
OBJECT-COMPUTER paragraph. used wherever NULL can be used.
* native collating sequence. The implementor-defined * numeric character. A character that belongs to the
collating sequence associated with the computer speci- following set of digits: 0, 1, 2, 3, 4, 5, 6, 7, 8, 9.
fied in the OBJECT-COMPUTER paragraph.
numeric-edited item. A numeric item that is in such a
* negated combined condition. The ‘NOT’ logical form that it may be used in printed output. It may
operator immediately followed by a parenthesized com- consist of external decimal digits from 0 through 9, the
bined condition. decimal point, commas, the dollar sign, editing sign
control symbols, plus other editing symbols.
* negated simple condition. The ‘NOT’ logical oper-
ator immediately followed by a simple condition. * numeric function. A function whose class and cate-
gory are numeric but which for some possible evaluation
nested program. A program that is directly contained does not satisfy the requirements of integer functions.
within another program.
* numeric item. A data item whose description restricts
* next executable sentence. The next sentence to its content to a value represented by characters chosen
which control will be transferred after execution of the from the digits from ‘0’ through ‘9’; if signed, the item
current statement is complete. may also contain a ‘+’, ‘-’, or other representation of an
operational sign.
* next executable statement. The next statement to
which control will be transferred after execution of the * numeric literal. A literal composed of one or more
current statement is complete. numeric characters that may contain either a decimal
point, or an algebraic sign, or both. The decimal point
* next record. The record that logically follows the must not be the rightmost character. The algebraic sign,
current record of a file. if present, must be the leftmost character.
Glossary 577
* output procedure. A set of statements to which * paragraph-name. A user-defined word that identifies
control is given during execution of a SORT statement and begins a paragraph in the Procedure Division.
after the sort function is completed, or during execution
of a MERGE statement after the merge function reaches parameter. Parameters are used to pass data values
a point at which it can select the next record in merged between calling and called programs.
order when requested.
password. A unique string of characters that a
overflow condition. A condition that occurs when a program, computer operator, or user must supply to
portion of the result of an operation exceeds the capacity meet security requirements before gaining access to
of the intended unit of storage. data.
* paragraph header. A reserved word, followed by the * prime record key. A key whose contents uniquely
separator period, that indicates the beginning of a para- identify a record within an indexed file.
graph in the IDENTIFICATION and ENVIRONMENT
DIVISIONs. The permissible paragraph headers in the * priority-number. A user-defined word which classifies
IDENTIFICATION DIVISION are: sections in the Procedure Division for purposes of seg-
mentation. Segment-numbers may contain only the
PROGRAM-ID. (Program IDENTIFICATION DIVISION) characters '0','1', ... , '9'. A segment-number may be
CLASS-ID. (Class IDENTIFICATION DIVISION) expressed either as a one- or two-digit number.
METHOD-ID. (Method IDENTIFICATION DIVISION)
AUTHOR.
* procedure. A paragraph or group of logically succes-
INSTALLATION.
sive paragraphs, or a section or group of logically suc-
DATE-WRITTEN.
DATE-COMPILED. cessive sections, within the Procedure Division.
SECURITY.
* procedure branching statement. A statement that
The permissible paragraph headers in the ENVIRON- causes the explicit transfer of control to a statement
MENT DIVISION are: other than the next executable statement in the
SOURCE-COMPUTER. sequence in which the statements are written in the
OBJECT-COMPUTER. source program. The procedure branching statements
SPECIAL-NAMES. are: ALTER, CALL, EXIT, EXIT PROGRAM, GO TO,
REPOSITORY. (Program or Class CONFIGURATION SECTION) MERGE, (with the OUTPUT PROCEDURE phrase),
FILE-CONTROL. PERFORM and SORT (with the INPUT PROCEDURE or
I-O-CONTROL. OUTPUT PROCEDURE phrase).
* program identification entry. An entry in the 2. A section-name that is used in a reference together
PROGRAM-ID paragraph of the IDENTIFICATION DIVI- with a paragraph-name specified in that section.
SION which contains clauses that specify the program- 3. A library-name that is used in a reference together
name and assign selected program attributes to the with a text-name associated with that library.
program.
* pseudo-text delimiter. Two contiguous equal sign * record area. A storage area allocated for the purpose
characters (==) used to delimit pseudo-text. of processing the record described in a record
description entry in the File Section of the DATA DIVI-
* punctuation character. A character that belongs to SION. In the File Section, the current number of char-
the following set: acter positions in the record area is determined by the
Character Meaning explicit or implicit RECORD clause.
, comma
; semicolon * record description. See “record description entry.”
: colon
. period (full stop) * record description entry. The total set of data
" quotation mark description entries associated with a particular record.
The term is synonymous with record description.
Glossary 579
recording mode. The format of the logical records in a Operator Meaning
file. Recording mode can be F (fixed-length), V IS GREATER THAN Greater than
(variable-length), S (spanned), or U (undefined). IS > Greater than
IS NOT GREATER THAN Not greater than
record key. A key whose contents identify a record IS NOT > Not greater than
within an indexed file.
IS LESS THAN Less than
* record-name. A user-defined word that names a IS < Less than
record described in a record description entry in the IS NOT LESS THAN Not less than
DATA DIVISION of a COBOL program. IS NOT < Not less than
routine. A set of statements in a COBOL program that * section-name. A user-defined word that names a
causes the computer to perform an operation or series section in the Procedure Division.
of related operations. In Language Environment, refers
selection structure. A program processing logic in
to either a procedure, function, or subroutine.
which one or another series of statements is executed,
* routine-name. A user-defined word that identifies a depending on whether a condition is true or false.
procedure written in a language other than COBOL.
* sentence. A sequence of one or more statements,
* run time. The time at which an object program is the last of which is terminated by a separator period.
executed. The term is synonymous with object time.
* separately compiled program. A program which,
run-time environment. The environment in which a together with its contained programs, is compiled sepa-
COBOL program executes. rately from all other programs.
* run unit. A stand-alone object program, or several * separator. A character or two contiguous characters
object programs, that interact via COBOL CALL state- used to delimit character-strings.
ments, which function at run time as an entity.
* separator comma. A comma (,) followed by a space
used to delimit character-strings.
S * separator period. A period (.) followed by a space
used to delimit character-strings.
SBCS (Single Byte Character Set). See “Single Byte
Character Set (SBCS).” * separator semicolon. A semicolon (;) followed by a
space used to delimit character-strings.
scope terminator. A COBOL reserved word that marks
the end of certain Procedure Division statements. It may sequence structure. A program processing logic in
be either explicit (END-ADD, for example) or implicit which a series of statements is executed in sequential
(separator period). order.
* section. A set of zero, one or more paragraphs or * sequential access. An access mode in which logical
entities, called a section body, the first of which is pre- records are obtained from or placed into a file in a con-
ceded by a section header. Each section consists of the secutive predecessor-to-successor logical record
section header and the related section body. sequence determined by the order of records in the file.
* section header. A combination of words followed by * sequential file. A file with sequential organization.
a separator period that indicates the beginning of a
section in the Environment, Data, and Procedure Divi- * sequential organization. The permanent logical file
sions. In the ENVIRONMENT and DATA DIVISIONs, a structure in which a record is identified by a
section header is composed of reserved words followed
Glossary 581
predecessor-successor relationship established when the * source computer entry. An entry in the
record is placed into the file. SOURCE-COMPUTER paragraph of the ENVIRON-
MENT DIVISION which contains clauses that describe
serial search. A search in which the members of a set the computer environment in which the source program
are consecutively examined, beginning with the first is to be compiled.
member and ending with the last.
* source item. An identifier designated by a SOURCE
* 77-level-description-entry. A data description entry clause that provides the value of a printable item.
that describes a noncontiguous data item with the level-
number 77. source program. Although it is recognized that a
source program may be represented by other forms and
* sign condition. The proposition, for which a truth symbols, in this document it always refers to a syntac-
value can be determined, that the algebraic value of a tically correct set of COBOL statements. A COBOL
data item or an arithmetic expression is either less than, source program commences with the IDENTIFICATION
greater than, or equal to zero. DIVISION or a COPY statement. A COBOL source
program is terminated by the end program header, if
* simple condition. Any single condition chosen from specified, or by the absence of additional source
the set: program lines.
Relation condition
Class condition * special character. A character that belongs to the
Condition-name condition following set:
Switch-status condition Character Meaning
Sign condition
+ plus sign
Single Byte Character Set (SBCS). A set of charac- - minus sign (hyphen)
ters in which each character is represented by a single * asterisk
byte. See also "EBCDIC (Extended Binary-Coded / slant (virgule, slash)
Decimal Interchange Code)." = equal sign
$ currency sign
slack bytes. Bytes inserted between data items or , comma (decimal point)
records to ensure correct alignment of some numeric ; semicolon
items. Slack bytes contain no meaningful data. In some . period (decimal point, full stop)
cases, they are inserted by the compiler; in others, it is " quotation mark
the responsibility of the programmer to insert them. The ( left parenthesis
SYNCHRONIZED clause instructs the compiler to insert ) right parenthesis
slack bytes when they are needed for proper alignment. > greater than symbol
Slack bytes between records are inserted by the pro- < less than symbol
grammer. : colon
SOM. See “System Object Model” * special-character word. A reserved word that is an
arithmetic operator or a relation character.
* sort file. A collection of records to be sorted by a
SORT statement. The sort file is created and can be SPECIAL-NAMES. The name of an ENVIRONMENT
used by the sort function only. DIVISION paragraph in which environment-names are
related to user-specified mnemonic-names.
* sort-merge file description entry. An entry in the
File Section of the DATA DIVISION that is composed of * special names entry. An entry in the
the level indicator SD, followed by a file-name, and then SPECIAL-NAMES paragraph of the ENVIRONMENT
followed by a set of file clauses as required. DIVISION which provides means for specifying the cur-
rency sign; choosing the decimal point; specifying sym-
* SOURCE-COMPUTER. The name of an ENVIRON-
bolic characters; relating implementor-names to
MENT DIVISION paragraph in which the computer envi-
user-specified mnemonic-names; relating alphabet-
ronment, within which the source program is compiled, is
names to character sets or collating sequences; and
described.
relating class-names to sets of characters.
* subject of entry. An operand or reserved word that * table element. A data item that belongs to the set of
appears immediately following the level indicator or the repeated items comprising a table.
level-number in a DATA DIVISION entry.
text deck. Synonym for object deck or object module.
* subprogram. See “called program.”
* text-name. A user-defined word that identifies library
* subscript. An occurrence number represented by text.
either an integer, a data-name optionally followed by an
integer with the operator + or -, or an index-name * text word. A character or a sequence of contiguous
optionally followed by an integer with the operator + or -, characters between margin A and margin R in a COBOL
that identifies a particular element in a table. A subscript library, source program, or in pseudo-text which is:
may be the word ALL when the subscripted identifier is A separator, except for: space; a pseudo-text delim-
used as a function argument for a function allowing a iter; and the opening and closing delimiters for non-
variable number of arguments. numeric literals. The right parenthesis and left
parenthesis characters, regardless of context within
Glossary 583
the library, source program, or pseudo-text, are * user-defined word. A COBOL word that must be
always considered text words. supplied by the user to satisfy the format of a clause or
statement.
A literal including, in the case of non-numeric
literals, the opening quotation mark and the closing
quotation mark that bound the literal.
V
Any other sequence of contiguous COBOL charac-
ters except comment lines and the word ‘COPY’ * variable. A data item whose value may be changed
bounded by separators that are neither a separator by execution of the object program. A variable used in
nor a literal. an arithmetic expression must be a numeric elementary
item.
top-down design. The design of a computer program
using a hierarchic structure in which related functions * variable length record. A record associated with a
are performed at each level of the structure. file whose file description or sort-merge description entry
permits records to contain a varying number of character
top-down development. See “structured positions.
programming.”
* variable occurrence data item. A variable occur-
trailer-label. (1) A file or data set label that follows the rence data item is a table element which is repeated a
data records on a unit of recording medium. (2) variable number of times. Such an item must contain an
Synonym for end-of-file label. OCCURS DEPENDING ON clause in its data description
entry, or be subordinate to such an item.
* truth value. The representation of the result of the
evaluation of a condition in terms of one of two values: * variably located group.. A group item following, and
true or false. not subordinate to, a variable-length table in the same
level-01 record.
unit. A module of direct access, the dimensions of VM/SP (Virtual Machine/System Product). An
which are determined by IBM. IBM-licensed program that manages the resources of a
single computer so that multiple computing systems
universal object reference. A data-name that can appear to exist. Each virtual machine is the functional
refer to an object of any class. equivalent of a “real” machine.
* unsuccessful execution. The attempted execution of volume. A module of external storage. For tape
a statement that does not result in the execution of all devices it is a reel; for direct-access devices it is a unit.
the operations specified by that statement. The unsuc-
cessful execution of a statement does not affect any volume switch procedures. System specific proce-
data referenced by that statement, but may affect status dures executed automatically when the end of a unit or
indicators. reel has been reached before end-of-file has been
reached.
UPSI switch. A program switch that performs the func-
tions of a hardware switch. Eight are provided: UPSI-0 VSAM/6000. A file system that supports COBOL
through UPSI-7. sequential, relative, and indexed organizations. This file
system is available as part of IBM COBOL Set for AIX.
Glossary 585
Index
adding records
Special Characters to files 103
-c cob2 option 136 ADDRESS special register, CALL statement 336
-cmain cob2 option 136 addresses
-comprc_ok cob2 option 136 incrementing 343
-F cob2 option 136 NULL value 342
-g cob2 option 136 passing between programs 341
-host cob2 option passing entry point addresses 344
-I cob2 option 137 ADEXIT suboption of EXIT compiler option 158, 161
-main cob2 option 137 AIX profiling, setting up object file 137
-o cob2 option 137 ALL subscript 40, 62
-p cob2 option 137 ALPHABET clause, establishing collating sequence 14
-pg cob2 option 137 alternate collating sequence 15, 109
-q cob2 command 138 alternate file system
-v cob2 option 138 file system ID 130
.c files 135 using environment variables 130
.adt file 149 alternate reserved word table, CICS 359
.wlist file 168 alternate reserved-word table 184
*CBL statement 187 ANALYZE compiler option 149
*CONTROL statement 187 ANNUITY intrinsic function 42
>>CALLINT statement 187 APOST compiler option 173
applications, porting
AIX to mainframe
Numerics AIX-only language features 321
2-digit years AIX-only names 321
querying within 100-year range (CEEQCEN) 516 AIX to OS/2 322
example 517 architectural differences between platforms 316
setting within 100-year range (CEESCEN) 518 language differences between AIX and
example 519 mainframe 316
valid values for 426 mainframe to AIX
3-digit years 426 choosing compiler options 316
4-digit years 426 running mainframe applications under AIX 317
using COPY to isolate platform-specific code 317
argument
A describing in calling program 337
abbreviated run-time messages 145 arguments
abbreviations, compiler options 147 IDL passing conventions 287
abends passing between C/C++ and COBOL 330
using ERRCOUNT run-time option to induce 194 passing between COBOL and C/C++ 332, 334
ACCEPT statement 7 passing BY VALUE 332
ACCEPT statement, defining environment to main program 351
variables 133 arithmetic
accessing local files 98 calculation on dates
using environment variables 130 convert date to COBOL Integer format
accessing remote files 98 (CEECBLDY) 484
ADATA compiler option 149 convert date to Lilian format (CEEDAYS) 498
convert timestamp to number of seconds
(CEESECS) 525
Index 587
callable services (continued) CEEGMT—get current Greenwich Mean Time
CEEGMTO—get offset from Greenwich Mean Time example 507
to local time 508 syntax 505
CEEISEC—convert integers to seconds 510 CEEGMTO—get offset from Greenwich Mean Time to
CEELOCT—get current local time 514 local time
CEEQCEN—query the century window 516 example 509
CEESCEN—set the century window 518 syntax 508
CEESECI—convert seconds to integers 521 CEEISEC—convert integers to seconds
CEESECS—convert timestamp to number of example 512
seconds 525 syntax 510
CEEUTC—get Coordinated Universal Time 530 CEELOCT—get current local time
date processing 438, 441 example 515
IGZEDT4—get current date with 4-digit year 530 syntax 514
CALLINT compiler option 150 CEEQCEN—query the century window
CALLINT statement 187 example 517
calls syntax 517
between COBOL programs 324 CEESCEN—set the century window
dynamic 327 example 519
exception condition 126 syntax 518
Linkage Section 338 CEESECI—convert seconds to integers
overflow condition 126 example 522
passing arguments 337 syntax 521
passing data 336 CEESECS—convert timestamp to number of seconds
receiving parameters 338 example 527
recursive 323 syntax 525
static 327 century encoding/compression
to date and time services 423 using as solution to the year 2000 problem 442
CANCEL statement century window
handling of programs name in 172 assumed for non-dates 464
CBL (PROCESS) statement 141 CEECBLDY callable service 486
CBL statement 187 CEEDAYS callable service 500
CEECBLDY—convert date to COBOL Integer format CEEQCEN callable service 517
example 484 CEESCEN callable service 518
syntax 484 CEESECS callable service 527
CEEDATE—convert Lilian date to character format concept 429
example 490 fixed 447
syntax 488 sliding 447
table of sample output 492 using as solution to the year 2000 problem 440
CEEDATM—convert seconds to character timestamp CESN transaction 358
CEESECI callable service 521 chained list processing 340
example 495 changing
syntax 493 characters to numbers 85
table of sample output 497 file-name 17
CEEDAYS—convert date to Lilian format title on source listing 13
example 501 CHAR compiler option 151
syntax 498 CHAR intrinsic function 86
CEEDYWK—calculate day of week from Lilian date character strings 158
example 503 character timestamp
syntax 502 converting Lilian seconds to (CEEDATM) 493
example 495
Index 589
collating sequence (continued) compiler options (continued)
MERGE 14 COMPILE 153
NATIVE 14 CURRENCY 154
non-numeric comparisons 14 DATEPROC 155
SEARCH ALL 14 DYNAM 433
SORT 14 ENTRYINT 157
specifying 14 EXIT 157
symbolic character in the 15 FLAG 162, 202
the ordinal position of a character 86 FLAGSTD 163
COLLSEQ compiler option 153 FLOAT 165
columns in tables 46 for application portability 316
command line arguments 351 for debugging 202
command prompt, defining environment variables 128 IDLGEN 165
COMMON attribute 13, 325 LIB 167
COMP (COMPUTATIONAL) 32 LINECOUNT 168
COMP-1 (COMPUTATIONAL-1) 33 LIST 168, 215
COMP-2 (COMPUTATIONAL-2) 33 MAP 169, 206, 211
COMP-3 (COMPUTATIONAL-3) 32 MAXMEM 169
COMP-4 (COMPUTATIONAL-4) 32 NOCOMPILE 205
compatible dates NUMBER 170, 210
with MLE 462 on compiler invocation 209
compilation OPTIMIZE 171, 432, 434
statistics 210 performance considerations 148
COMPILE compiler option 153 PGMNAME 172
use NOCOMPILE to find syntax errors 205 PROFILE 173
compile-time considerations QUOTE 173
compiling programs 136 selecting for CICS 360
executing programs 138 SEPOBJ 174
invoking the compiler 135 SEQUENCE 175, 205
compile-time error messages SIZE 176
choosing severity to be flagged 202 SOURCE 176, 210
embedding in source listing 202 SPACE 177
compiler specifying
calculation of intermediate results 471 order of precedence 141
limits 18 using COBOPT 129
compiler environment variables 128 using PROCESS (CBL) statement 141
compiler error messages 142 SPILL 177
correcting mistakes 144 SQL 177, 354
determining what severity level to produce 162 SSRANGE 178, 206, 434
generating a list of 145 status 209
severity levels 143 TERMINAL 178
compiler options TEST 179, 435
abbreviations 147 THREAD 179
ADATA 149 TRUNC 180
ANALYZE 149 TRUNC(STD|OPT|BIN) 435
APOST 173 TYPECHK 183
BINARY 150 VBREF 184, 215
CALLINT 150 WORD 184
CHAR 151 WSCLEAR 185
COLLSEQ 153 XREF 185, 205, 216
Index 591
data item (continued)
D reversing characters 84
data splitting 75
See also numeric data variably-located 479
checking validity 37 data items
concatenating 73 unused 171
format conversion 35 data representations, portability 318
format, numeric types 30 data types
grouping 339 correspondence between COBOL and C/C++ 329
incompatible 37 data- and procedure-name cross reference,
joining 73 description 216
numeric 29 data-manipulation
passing 336 non-numeric data 73
splitting 75 data-name
validation 37 in MAP listing 212
data areas, dynamic 156 reference modification 108
data definition 212 date and time
data definition attribute codes 212 format
data description entry, description 18 converting from character format to COBOL
DATA DIVISION Integer format (CEECBLDY) 484
class 225, 226 converting from character format to Lilian format
client 238 (CEEDAYS) 498
coding 18 converting from integers to seconds
description 18 (CEEISEC) 510
FD entry 18 converting from Lilian format to character format
FILE SECTION 18 (CEEDATE) 488
limits 18 converting from seconds to character timestamp
LINKAGE SECTION 21 (CEEDATM) 493
listing 211 converting from seconds to integers
mapping of items 211 (CEESECI) 521
method 229 converting from timestamp to number of seconds
OCCURS clause 46 (CEESECS) 525
restrictions 18 getting date and time (CEELOCT) 514
WORKING-STORAGE SECTION 19 services
DATA DIVISION items, mapping 169 CEECBLDY—convert date to COBOL Integer
data item format 484
common, in subprogram linkage 338 CEEDATE—convert Lilian date to character
concatenating 73 format 488
converting 82 CEEDATM—convert seconds to character
converting characters to numbers 85 timestamp 493
converting to uppercase/lowercase 84 CEEDAYS—convert date to Lilian format 498
converting with intrinsic functions 84 CEEDYWK—calculate day of week from Lilian
counting 82 date 502
evaluating with intrinsic functions 86 CEEGMT—get current Greenwich Mean
finding the smallest/largest in group 86 Time 505
index 48 CEEGMTO—get offset from Greenwich Mean
numeric 29 Time to local time 508
reference modification 79 CEEISEC—convert integers to seconds 510
referencing substrings 79 CEELOCT—get current local time 514
replacing 82 CEEQCEN—query the century window 517
CEESCEN—set the century window 518
Index 593
diagnostics, program 210 entry point (continued)
differences with host COBOL 466 passing entry addresses of 344
direct-access procedure-pointer data item 344
direct indexing 50 entry points, call convention 157
DISPLAY (USAGE IS) 31 ENTRY statement
DISPLAY statement handling of programs name in 172
using in debugging 197 ENTRYINT compiler option 157
DISPLAY statement, defining environment ENV environment variable 128
variables 133 environment differences, System/390 and AIX 320
displaying compile and link steps 138 ENVIRONMENT DIVISION
Distributed Computing Environment (DCE), support class 224
for 398 client 238
documentation of program 13 collating sequence coding 14
dumps, when not produced 195 CONFIGURATION SECTION 13
DYNAM compiler option 156 description 13
description 156 INPUT-OUTPUT SECTION 16
performance considerations 433 method 229
dynamic calls subclass 244
using in a CICS environment 361 environment file 128
dynamic link libraries environment variables
CICS considerations 362 assignment-name 130
dynamic linking 327 COBMSGS 131
linker resolution of shared library references 387 COBOPT 129
terminology 387 DB2DBDFT 130
dynamically called programs, locating 131 defining multiple directory paths 134
EBCDIC_CODEPAGE 131
for file names 130
E for library-name 129
E-level error message 202 for text-name 129
E-level message 143 LIBPATH 132
EBCDIC library-name 190
DBCS portability 319 LOCPATH 132
portability considerations 318 requirements when running programs 145
EBCDIC_CODEPAGE environment variable 131 run time 130
EJECT statement 187 setting 128
embedded cross-reference 218, 219 SYSLIB 129
embedded error messages 202 System Object Model (SOM) 270
embedded MAP summary 206, 213 text-name 190
embedded SQL TZ 133
advantages 370 environment-name 13
Encina SFS files environment, pre-initializing 334
accessing 90, 130, 363 ERRCOUNT run-time options 194
compiling for (cob2_r4) 135 ERRMSG, for generating a listing of compiler
processing files 90 messages 145
Encina SFS files, accessing 96, 97 error
enclave 323 arithmetic 117
end-of-file phrase (AT END) 120 example of message table 54
ENTER statement 187 handling 116
entry point messages, compiler
ENTRY label 323 choosing severity to be flagged 202
embedding in source listing 202
Index 595
FILE SECTION (continued) finding the length of data items 88
GLOBAL clause 19 finding the smallest or largest data item 86
FILE STATUS clause fixed century window 447
file loading 100 fixed-point arithmetic
using 121 comparisons 44
with VSAM return code 123 evaluation 43
file status key example evaluations 45
checking for successful OPEN 121, 122 fixed-point data
set for error handling 199 binary 32
to check for I/O errors 121 conversions between fixed- and floating-point
used with VSAM return code 123 data 36
file system ID 130 external decimal 31
file system support intermediate results 473
Encina SFS 194 packed decimal 32
STL 194 fixed-point exponentiation 473
using FILESYS run-time option to access 194 FLAG compiler option 162
VSAM 194 compiler output 203
file-name description 202
change 17 flags 67
files FLAGSTD compiler option 163
accessing local files 98 FLOAT compiler option 165
accessing remote files 98 floating-point arithmetic
accessing using environment variables 130 comparisons 44
adding records to 103 evaluation 43
affected by TRAP run-time option 195 example evaluations 45
associating program files to external files 13 floating-point data 319
COBOL coding conversions between fixed- and floating-point
overview 94 data 36
comparison of file organizations 92 external floating-point 31
compiling multiple files 135 intermediate results 477
deleting records from 104 internal 33
Encina SFS 363 floating-point exponentiation 477
file position indicator 100, 102 four-digit year dates 436
input/output error processing 118 full date field expansion
opening 100 advantages 453
path search order 134
processing
Encina SFS files 90 G
STL files 90 GETMAIN, saving address of 158
VSAM files 90 GLOBAL clause for files 19
reading records from 101 global names 327
rejected by the linker 135 GMT
replacing records in 104 See Greenwich Mean Time
RSD 96 GOBACK statement
STL 96 in main program 324
updating records 102 in subprogram 324
usage explanation 17 Greenwich Mean Time (GMT)
VSAM 96 getting offset to local time from (CEEGMTO) 508
FILESYS run-time options 194 return Lilian date and Lilian seconds
(CEEGMT) 505
Index 597
initializing intrinsic functions (continued)
a table 52 compatibility with CEELOCT callable service 514
input converting character data items 84
overview 91 DATEVAL 458
input procedure evaluating data items 86
requires RELEASE or RELEASE FROM 110 example of
restrictions 111 ANNUITY 42
using 109 CHAR 86
INPUT-OUTPUT SECTION 16 CURRENT-DATE 41
input/output INTEGER 82
checking for errors 121 INTEGER-OF-DATE 41
coding overview 94 LENGTH 41, 87, 88
introduction 91 LOG 43
logic flow after error 118 LOWER-CASE 84
processing errors for files 118 MAX 63, 86, 87
input/output coding MEAN 43
AT END (end-of-file) phrase 120 MEDIAN 43, 63
checking for successful operation 121 MIN 82
checking VSAM return codes 123 NUMVAL 85
detecting faulty index key 125 NUMVAL-C 41, 85
error handling techniques 118 ORD 86
EXCEPTION/ERROR declaratives 120 ORD-MAX 63, 87
INSERT statement 187 PRESENT-VALUE 42
INSPECT statement 82 RANGE 43, 63
inspecting data 82 REM 43
integer format date REVERSE 84
using as solution to the year 2000 problem 442 SQRT 43
INTEGER intrinsic function 82 SUM 63
INTEGER-OF-DATE intrinsic function 41 UPPER-CASE 84
integers WHEN-COMPILED 88
converting Lilian seconds to (CEESECI) 521 intermediate results 475, 477
converting to Lilian seconds (CEEISEC) 510 introduction to 9
Interface Repository (IR) nesting 10
accessing 269 numeric functions
definition 269 examples of 40
populating 269 nested 40
interlanguage communication special registers as arguments 40
between COBOL and C/C++ 328 table elements as arguments 40
intermediate results 471 type of—integer, floating-point, mixed 40
internal bridges uses for 40
advantages 450 processing table elements 62
for date processing 449 reference modification of 81
internal bridging simplifies coding 422
date processing solution 439 UNDATE 459
internal floating-point data INVALID KEY phrase 125
bytes required 33 INVOKE statement
defining 33 use with PROCEDURE DIVISION RETURNING 345
uses for 33 invoking
intrinsic functions date and time services 423
as reference modifier 82
Index 599
LOG intrinsic function 43 metaclass definition 258
loops method definition 228
coding 70 METHOD-ID paragraph 229
conditional 71 methods 240
in a table 71 invoking from CICS programs 363
performed a definite number of times 71 PROCEDURE DIVISION RETURNING 345
LOWER-CASE intrinsic function 84 millennium bug 446
lowercase 84 millennium language extensions 446
assumed century window 464
compatible dates 462
M compiler options affecting 147
main program concepts 462
and subprograms 323 date windowing 447
arguments to 351 DATEPROC compiler option 155
specifying with cob2 136, 137 non-dates 463
MAP compiler option 169, 206, 211 objectives 461
embedded MAP summary 212 performance aspects 444
example 211, 214 principles 461
nested program map 214 YEARWINDOW compiler option 186
terms used in output 214 MIN intrinsic function 82, 86
mapping of DATA DIVISION items 211 MIXED suboption of PGMNAME 173
maps and listings 147 MLE 446
mathematics mnemonic-name
intrinsic functions 40, 43 SPECIAL-NAMES paragraph 13
MAX intrinsic function 63, 86, 87 modules, exit
MAXMEM compiler option 169 loading and invoking 159
MEAN intrinsic function 43, 63 MOVE statement 7
MEDIAN intrinsic function 43, 63 multiple PROCESS statements 142
merge multiple thread environment, running in 179
concepts 105 multitasking 398
description 105 multithreading
files, describing 105 control transfer issues 401
successful 111 limitations on COBOL 402
MERGE statement overview 397
description 111 preparing COBOL programs for 397
MERGE work files 133 scope of language elements
messages program invocation instance scoped
abbreviated or incomplete, cause of 145 elements 400
compile-time error run-unit scoped elements 400
choosing severity to be flagged 202 synchronizing access to resources 402
embedding in source listing 202 terminology 397
compiler 142 THREAD compiler option
determining what severity level to produce 162 recursion 401
displaying error line number 145 restrictions under 400
formatting time and date information 132 when to choose 400
indicating language display 132
run-time 532
specifying path name 132 N
when core file is created 145 naming
when not produced 195 programs 12
Index 601
object file, setting up 137 optimization
object module, naming 137 contained program integration 432
object references 239 effect of compiler options on 433
OBJECT-COMPUTER paragraph 13 nested program integration 432
object-oriented COBOL unused data items 171
generating IDL definitions 165 OPTIMIZE compiler option 171
restrictions for DYNAM compiler option 156 affect on performance 432
support under CICS 363 description 432
objectives of millennium language extensions 461 performance considerations 434
OCCURS clause 46 optimizer 431
OCCURS DEPENDING ON (ODO) clause optional words xxi
complex 59, 479 ORD intrinsic function 86
initializing ODO elements 53 ORD-MAX intrinsic function 63, 87
simple 56 ORD-MIN intrinsic function 87
variable-length tables 56 order of precedence, compiler option specification 141
ODBC 369 OS/2, porting to 322
accessing return values 376 output
advantages 370 overview 91
background 369 output procedure
CALL interface convention 371 requires RETURN or RETURN INTO statement 110
driver manager 369 restrictions 111
embedded SQL 370 using 110
mapping of C data types 373 overflow condition 116, 126
passing a COBOL pointer to 373
sample program 377
supplied copybooks 371 P
supplied odbc3.cpy 377 packed decimal data item
supplied odbc3d.cpy 377 general description 32
supplied odbc3p.cpy 377 using efficiently 32
using APIs from COBOL 370 PACKED-DECIMAL
using the drivers 370 general description 32
odbc3.cpy 377 synonym 30
odbc3d.cpy 377 using efficiently 32
odbc3p.cpy 377 page header 209, 210, 211
ODO (OCCURS DEPENDING ON) clause paragraph
simple 56 grouping 72
variable-length tables 56 introduction 23
OMITTED parameters 423 parameter
ON SIZE ERROR phrase describing in called program 338
with windowed date fields 456 in main program 351
OO COBOL parameter list
generating IDL definitions 165 address of with INEXIT 159
Open Database Connectivity (see ODBC) 369 for ADEXIT 161
OPEN operation code 159 for PRTEXIT 161
OPEN statement passing addresses between programs 341
file availability 100 passing data between programs
file status key 121 BY CONTENT 336
opening files 100 BY REFERENCE 336
using environment variables 130 BY VALUE 336
called program 337
Index 603
procedure-pointer data item (continued) record (continued)
SET statement and 344 format 91
PROCESS (CBL) statement 141 records, affected by TRAP run-time option 195
processes 397 recursive calls 12, 323
processing and the LINKAGE SECTION 21
chained list 340 reference modification
tables 54 example 80
using indexing 56 of an intrinsic function, example 81
using subscripting 55 out-of-range values 80
PROFILE compiler option 173 tables 51, 82
profiling support, PROFILE option 173 reference modifier
program arithmetic expression as 81
attribute codes 215 intrinsic function as 82
decisions variables as 80
EVALUATE statement 66 relate items to system-names 13
IF statement 64 relation condition 66
loops 71 relative file organization 92
PERFORM statement 71 Relative files
switches and flags 67 file access mode 93
diagnostics 210 RELEASE FROM statement
main 323 compared to RELEASE 110
nesting level 211 example 110
statistics 210 RELEASE statement
structure 12 compared to RELEASE FROM 110
sub 323 with SORT 108, 110
PROGRAM COLLATING SEQUENCE clause 14 REM intrinsic function 43
program entry points, call convention 157 REPLACE statement 187
program names, handling of case 172 replacing
PROGRAM-ID paragraph data items 82
COMMON attribute 13 records in file 104
description 12 REPOSITORY paragraph 13, 225
INITIAL attribute 13 representation
program-name cross-reference 218 data 37
programs, running 145 sign 37
PRTEXIT suboption of EXIT option 158, 161 required words xx
reserved word table
CICS 359
Q restrictions
QUOTE compiler option 173 indexing 50
input/output procedures 111
subscripting 49
R return code
RANGE intrinsic function 43, 63 feedback code from date and time services 423
reading records from files from DB2 357
dynamically 102 RETURN-CODE special register 345, 423
randomly 102 VSAM files 123
sequentially 101 when control returns to operating system 345
receiving field 75 RETURN INTO statement 110
record RETURN statement 110
description 18
Index 605
severe errors, creates core file 145 SORT statement
severity codes for error messages 143 description 107
SFS (Encina) files SORT work files 133
processing files 90 SORT-RETURN special register 112
SFS files (Encina) source code
accessing 90, 130, 363 line number 211, 212, 215
compiling for (cob2_r4) 135 listing, description 210
SFS files (Encina), accessing 96, 97 SOURCE compiler option 176, 210
shared libraries SOURCE-COMPUTER paragraph 13
advantages and disadvantages 386 SPACE compiler option 177
building 386 special feature specification 13
linker resolution of references 387 special register
overview 386 ADDRESS 336
overview of shared libraries 386 arguments in intrinsic functions 40
purpose 386 LENGTH OF 88, 337
subprograms and outermost programs 387 WHEN-COMPILED 88
terminology 387 special registers
sharing SORT 112
See also passing data SORT-CONTROL 112
data 327, 346 SORT-RETURN 112
files 19, 327, 346 SPECIAL-NAMES paragraph 13
sign condition 66 for collating sequence 14
sign representation 37 SPILL compiler option 177
SIZE compiler option 176 splitting data items 75
SKIP1/2/3 statement 187 SQL compiler option 177, 354
sliding century window 447 SQL INCLUDE statement 356
SMARTdata Utilities 98 SQL statements 354
SOM 275 SQL statements supported 357
CORBA-style exceptions 297 SQLCA 354
environment arguments 297 SQLCODE 357
errors and exceptions 297 SQLSTATE 357
COBOL example 298 SQRT intrinsic function 43
initializers 301 SSRANGE compiler option 178
memory management with 304 CHECK(OFF) run-time option 434
SOMerror-style exceptions 297 description 206
sort performance considerations 434
alternate collating sequence 109 stacked words xxi
concepts 105 statement
criteria 108 compiler-directing 25
description 105 conditional 24
files, describing 105 definition 24
more than one 105 delimited scope 26
restrictions on input/output procedures 111 explicit scope terminator 25
special registers 112 imperative 24
successful 111 implicit scope terminator 25
terminating 112 statement nesting level 211
using input procedures 109 static linking 327
using output procedures 110 advantages and disadvantages 386
Sort File Description (SD) entry overview 386
example 106 terminology 387
Index 607
table (continued) UNDATE intrinsic function 459
variable-length 56 UNSTRING statement
TALLYING option 82 description 75
TEMP environment variable 133 example 75
TERMINAL compiler option 178 overflow condition 116
terminal, sending messages to 178 updating records 102
terminology UPPER suboption of PGMNAME 172
introduction to COBOL terms 2 UPPER-CASE intrinsic function 84
static and dynamic linking 387 uppercase 84
terms used in MAP output 214 UPSI run-time options 196
test UPSI switches, setting 196
data 66 USAGE clause
for values 66 incompatible data 37
numeric operand 66 IS INDEX 51
UPSI switch 66 USE EXCEPTION/ERROR declaratives 198
TEST compiler option 179 USE FOR DEBUGGING declarative 193
performance considerations 435 USE FOR DEBUGGING declaratives 199
THREAD compiler option 179 USE statement 187
and the LINKAGE SECTION 21 user-defined condition 66
use cob2_r 135 user-exit work area 158
threading (see "multithreading") UTC (Coordinated Universal Time)
time and date information, formatting 132 See Greenwich Mean Time
time zone information
specifying with TZ 133
time, getting local (CEELOCT) 514 V
timestamp 493, 525 valid data 37
TITLE statement 187 VALUE clause
controlling header on listing 13 assigning table values 52
titles Data Description entry 54
controlling header on listing 13 VALUE IS NULL 342
transferring control variable
between COBOL programs 324 as reference modifier 80
called program 323 COBOL term for 2
calling program 323 variable-length table 56
main and subprograms 323 variables, environment 128
translating CICS into COBOL 358 COBMSGS 131
TRAP run-time option 195 EBCDIC_CODEPAGE 131
ON SIZE ERROR 117 LIBPATH 132
TRUNC compiler option 32, 180 library-name 129, 190
TRUNC(STD|OPT|BIN) compiler option 435 LOCPATH 132
trunction, binary 32 SYSLIB 129
tuning considerations, performance 433 text-name 129, 190
TYPECHK compiler option 183 TZ 133
TZ environment variable 133 variably-located data item 479
variably-located group 479
VBREF compiler option 184, 215
U verb cross-reference listing
U-level error message 202 description 215
U-level message 143 verbs used in program 215
X
XREF compiler option 185, 205, 216
Y
year 2000 Problem
century encoding/compression solution 442
century window solution 440
explanation 436
field expansion solution 437
integer format date solution 442
internal bridging 439
mixed solution 441
Index 609
We'd Like to Hear from You
COBOL Set for AIX
Programming Guide
Release 1
Publication No. SC26-8423-03
Please use one of the following ways to send us your comments about this book:
Mail—Use the Readers' Comments form on the next page. If you are sending the form from a
country other than the United States, give it to your local IBM branch office or IBM represen-
tative for mailing.
Fax—Use the Readers' Comments form on the next page and fax it to this U.S. number:
800-426-7773.
Electronic mail—Use one of the following network IDs:
– IBMMail: USIB2VVG at IBMMAIL
– IBMLink: COBPUBS at STLVM27
– Internet: [email protected]
Be sure to include the following with your comments:
– Title and publication number of this book
– Your name, address, and telephone number if you would like a reply
Your comments should pertain only to the information in this book and the way the information is
presented. To request additional publications, or to comment on other IBM information or the
function of IBM products, please give your comments to your IBM representative or to your IBM
authorized remarketer.
Very Very
Satisfied Satisfied Neutral Dissatisfied Dissatisfied
Technically accurate Ø Ø Ø Ø Ø
Complete Ø Ø Ø Ø Ø
Easy to find Ø Ø Ø Ø Ø
Easy to understand Ø Ø Ø Ø Ø
Well organized Ø Ø Ø Ø Ø
Applicable to your tasks Ø Ø Ø Ø Ø
Grammatically correct and con-
sistent Ø Ø Ø Ø Ø
Graphically well designed Ø Ø Ø Ø Ø
Overall satisfaction Ø Ø Ø Ø Ø
Name Address
Company or Organization
Phone No.
Cut or Fold
Readers' Comments
IBM
Along Line
SC26-8423-03
NO POSTAGE
NECESSARY
IF MAILED IN THE
UNITED STATES
Department J58
International Business Machines Corporation
PO BOX 49023
SAN JOSE CA 95161-9945
Cut or Fold
SC26-8423-03 Along Line
IBM
SC26-8423-ð3
Spine information: