HSBC - COBOL Estandard de Codificacion

Developer Handbook
COBOL Coding Standard
Version 1.0
December 2005
©COPYRIGHT HSBC HOLDINGS PLC 2005. ALL RIGHTS RESERVED.
No part of this publication may be reproduced, stored in a retrieval system, or transmitted, on any form or by any
means, electronic, mechanical, photocopying, recording, or otherwise, without the prior written permission of HSBC
HOLDINGS PLC.
Developer Handbook Version 1.0
COBOL Coding Standard December 2005
Revision History
Date Version Status Comments
Sep 2005 0.1 Draft Initial draft for internal review.
Nov 2005 0.2 Draft Draft with revisions for comments.
Dec 2005 0.3 Draft Draft with revisions for comments.
Dec 2005 1.0 Final Same as version 0.3 which has been reviewed by ESD
Regional Domain Owners and Software Architecture
Board (SAB) members.
Document Control
Role Name e-mail Telephone
Owner ESD Global Domain Annie L Y LOK/SM IT +852 22881188
APH/HBAP/HSBC
Preparer Jimmy Choi, Alvin Law
Reviewed By
Reviewer Domain Unit / Region Date
Jeff Wolfers Group IT Architecture
Adrian Musson Software Architecture Board
Nancy Wong Group Messaging Framework
Gerald Vaughan Data Architecture
John Flood Enterprise Presentation Services
Debbie Talamo Integration Technologies
Tony Sullivan Conceptual Application Architecture
Louise Galbraith Development Methods & Methodologies
Colin Milton-Haynes Security Architecture
David Bagge CIBM UK

Didier Balanger HBFR
Federico Munguia HBMX
Greg Ryan HTSE
Mike Saul HTSE
Oscar Lo HBCA
Patrick Scire PBRS
David Hanson HTSU
Raghu Muktineni HTSU (Installing Lending)
Sergio Razente HBBR
Vivek Ransubhe GLTi
Confidential ©HSBC HOLDINGS PLC, 2004 Page ii

Table of Contents
1. INTRODUCTION .....................................................................................................................1
1.1. OVERVIEW ............................................................................................................................1
1.2. OBJECTIVES AND INTENDED AUDIENCE ................................................................................1
1.3. DOCUMENT STRUCTURE .......................................................................................................1
1.4. RELATED DOCUMENTS .........................................................................................................1
2. CODING STANDARDS ...........................................................................................................2
2.1. STRUCTURE ..........................................................................................................................2
2.1.1. Terminology ...................................................................................................................2
2.1.2. Naming Conventions ......................................................................................................3
2.1.3. Program Structure...........................................................................................................6
2.1.4. Subprogram Structure.....................................................................................................8
2.1.5. Subroutine Structure .....................................................................................................10
2.1.6. Sequence .......................................................................................................................10
2.1.7. Spacing and new page ..................................................................................................14
2.1.8. Indentation ....................................................................................................................14
2.1.9. Use of END-Verbs........................................................................................................15
2.1.10. Position of source code program amendments .............................................................16
2.2. DOCUMENTATION ...............................................................................................................18
2.2.1. Overview.......................................................................................................................18
2.2.2. Program Documentation...............................................................................................18
2.2.3. Subprogram Documentation.........................................................................................22
2.2.4. Subroutine Documentation ...........................................................................................23
2.2.5. Comments in code ........................................................................................................24
2.3. MACRO COPYBOOKS ..........................................................................................................25
2.3.1. Data Macros..................................................................................................................25
2.3.2. Procedure Coding Macros ............................................................................................32
2.4. PROGRAM DIVISIONS CODING RULES .................................................................................33
2.4.1. General Coding Standards ............................................................................................33
2.4.2. Identification Division Coding Rules ...........................................................................34
2.4.3. Environment Division Coding Rules............................................................................35
2.4.4. Data Division Coding Rules .........................................................................................36
2.4.5. Procedure Division Coding Rules ................................................................................39
2.5. PROGRAM INTERFACES .......................................................................................................54
2.5.1. Processing External Data..............................................................................................54
2.5.2. Intercommunication between Programs .......................................................................55
2.5.3. Program Messages ........................................................................................................56
2.6. ERROR HANDLING ..............................................................................................................58
2.7. ONLINE PROGRAMMING CONSIDERATIONS .........................................................................59
2.7.1. General standard ...........................................................................................................59
2.8. CODING FOR PERFORMANCE ...............................................................................................61
2.8.1. General COBOL Program ............................................................................................61
2.8.2. Online COBOL Program ..............................................................................................66
A. REFERENCES ........................................................................................................................67
Confidential ©HSBC HOLDINGS PLC, 2004 Page iii

Confidential ©HSBC HOLDINGS PLC, 2004 Page iv

1. Introduction
1.1. Overview
This document describes the standards and guidelines for COBOL programming. With a set
of global development standards and guidelines for COBOL programming, we expect to
facilitate COBOL program developers to produce high quality, easily maintained and more
reusable COBOL codes that work seamlessly with the GOLD Standard.
This document does not describe any basic COBOL syntax and operation. It also does not
cover the coding practice such as customization/localization, package release & upgrade
methodologies for the GOLD and Evergreen Strategy. Such contents can be found in
COBOL Coding Practice document.
1.2. Objectives and Intended Audience
These development standards and guidelines are defined to promote high quality COBOL
programs in terms of:
• Maintainability
• Reusability
• Efficiency, and
• Understandability & readability
Target audiences are project managers, system analysts and programmers who work on
COBOL programming projects.
1.3. Document Structure
The document firstly describes proper format of source programs layout in a well-structured,
standardized and straightforward manner. Then, it describes the documentation standard of
macros copybooks and programs. Program coding rules, error handling and coding for
performance are then discussed to provide guidelines to optimize programs for the future
maintenances, developments and reuses.
1.4. Related Documents
The COBOL Coding Practice document describes the customization/localization for the
GOLD and Evergreen Strategy. Modular programming and package release & upgrade
methodologies are also discussed to provide guidelines for COBOL developers to work with
the GOLD Standard.
Confidential ©HSBC HOLDINGS PLC, 2005 Page 1

2. Coding Standards
2.1. Structure
2.1.1. Terminology
The terms 'program', 'main program, 'subprogram' and ‘subroutine’/'routine' are used
throughout this section. These terms are defined below.
Program
A program is an entity which can be executed (from a JCL 'EXEC' statement or in
response to the receipt of a CICS screen or task code from a terminal, for example).
In general case, a program comprises a 'main program' and several separately compiled
'subprograms', all of them are bound (link-edited) together.
Main Program
The main program controls overall flow of program logic. In an LE/370 environment, the
first COBOL program loaded into the run unit is the main program.
Subprogram
A subprogram is a separately compiled logical unit of code which is designed to perform
one (or more) functions of the program. A subprogram is invoked with either a static or
dynamic CALL statement. In CICS system, when control is transferred from active
program to an external program, but the program remains active and control can be
returned to it, the program to which the control is transferred is call a subprogram. In CICS
system, the subprogram is invoked with either a static CALL statement, or a dynamic
CALL statement, or a LINK statement. A subprogram is also often called “module”.
Subroutine/Routine
“Subroutine” and “Routine” are commonly used interchangeably. A subroutine is
equivalent to a section or a paragraph in the Procedure Division of a main program or a
subprogram. Each subroutine is designed to perform a distinct processing function (eg,
validate input data, calculate interest amount due, update savings account details, display
an error message).
The start of a subroutine is denoted by a section or paragraph name. A subroutine is

invoked with a PERFORM statement.

2.1.2. Naming Conventions
2.1.2.1. Global Naming Conventions
Global Program Naming Methodology
For example: SSSCXXXX
1st – 3rd 4th 5th – 8th

Characters Character Characters
SSS = C= XXXX =
System / Program characteristics Unique alphanumeric characters
Application indicator (assigned by (assigned by development team),
mnemonic development team) the first character is compulsory
(Globally and the others can be optional
assigned)
e.g.
e.g. OBS N = Online
S = Sub-program
D = Daily
W = Weekly
M = Monthly
Q = Quarterly
B = Bi-annually
H = Half-year
Y = Yearly
P = Periodically
Figure 2.1 Table of global program naming fields specification
Example:
SSSD0001 - SSS system daily program 0001
SSSS0001 - SSS system sub-program 0001
SSSNAB01 - SSS system online program AB01

Global Macros Naming
For example: SSSXXXXF
1st – 3rd 4th – 7th 8th

Characters Characters Characters
SSS = XXXX = F=
System Unique macro sequence Function indicator
/Application number or name
mnemonic (assigned by development
(Globally team)
assigned) e.g.
G = Procedure Coding
e.g. OBS R = Customisation
Procedure Coding
W = Working Storage
X = Customisation
Working Storage
Q = File Assign Statement
V = VSAM File Assign
F = File Description
L = Interface Macro
D = Driver
S = Subroutines
N = Record Layout
I = Initializer Record
Figure 2.2 Table of global macro naming fields specification
Example:
SSSZZZZG - SSS system coding macro
SSSZZZZR - SSS system coding macro for customization
SSSZZZZW - SSS system working storage macro
SSSZZZZX - SSS system working storage macro for customization
SSSZZZZQ - SSS system working storage file assign statement macro of
working storage SSSZZZZW
SSSZZZZF - SSS system working storage file description macro of working
storage SSSZZZZW
SSSZZZZL - SSS system interface macro used as a parameter in the linkage
section

Global Naming Methodology
The following table demonstrates global naming methodology. The table shows the
relationships between sub-program and it’s macro, coding macro and it’s
corresponding macro, file working storage and it’s corresponding macros. Same
XXXXn denotes the same name fragment of the names of related program entities.
The example here contains a daily program that calls a sub-program, and contains a
procedure coding macro. The program contains one working storage and one file
input:
Description Program Sub- Program Macros

Program Coding Macro
Macro
A program SSS1DXXXX1
A sub-program SSS2SXXXX2 SSS2XXXX2W

optionally with (For input or
an associated output parameter
macro for options)
parameter
options
A coding macro SSS3XXXX3W

with input or SSS3XXXX3G SSS3XXXX3X
output SSS3XXXX3R
parameters and
local working
storage
A working SSS4XXXX4W
storage macro
possibly be used
by more than one
program
A set of file SSS5XXX5[X]W

related macros (For file working
for working storage, character
storage, file [X] is optional)
assign statement SSS5XXX5[X]Q
and file (For file assign
definition statement,
character [X] is
optional for
denoting
input(I)/Output(O)
SSS5XXX5[X]V
(For file assign
statement,
character [X] is
optional for
denoting
input(I)/Output(O)

SSS5XXX5[X]F
(For file
definition,
character [X] is
optional for
denoting
input(I)/Output(O)
An interface SSS6XXXX6L
macro possibly
be used by more
than one program
Figure 2.3 Table of global naming general example
2.1.3. Program Structure
During the Design phase of the Risk Based Project Management (RBPM), a program is
normally divided into a set of subprograms which are arranged in a hierarchy defining their
logical and execution-time relationships, as illustrated by the structure chart in Figure 2.4.
The main program at the top of the hierarchy (level 1) defines the overall flow of the
program logic. This main program calls subprograms at level 2 to perform certain
functions. These level 2 subprograms in turn call level 3 subprograms, etc.
At the lowest level are various common subprograms which perform widely used basic
functions. These subprograms may be called from anywhere in the hierarchy.
The main program:
- defines the overall flow of the program logic and contains the major logical
decisions,
- contains the only normal exit point of the program.
Each of the subprograms normally:
- performs one (or more) of the functions of the program,
- has only one entry point (the first statement in the Procedure Division),
- has only one exit point (the last statement, i.e. GOBACK, in the Procedure Division).
The execution flow between subprograms is restricted to a scheme in which control enters
the called subprogram at its single entry point, and leaves from its one exit point. Control
is always returned to the calling subprogram.

Size of subprogram should restrict to reasonable number of statements and program developer
should not implement too many codes in a subprogram.
Level 1
Level 2
Level 3
Figure 2.4 Program Hierarchy Chart

2.1.4. Subprogram Structure
In the same way as a program is divided into a number of subprograms, each subprogram
should be further divided into a set of carefully structured routines, with a mainline routine
directing the execution of groups of independent processing routines performing intricate,
peripheral or exception processing.
These routines should also be structured into hierarchies (as illustrated by the subprogram
Hierarchy Chart in Figure 2.5).
The mainline routine at the top of the hierarchy (level 1) defines the overall flow of the
logic. This routine invokes routines at level 2 to perform certain processing. These level 2
routines in turn invoke level 3 routines etc.
At the lowest level are various common routines which perform widely used basic
processing functions (e.g., read a record, display an error message). These routines may be
invoked from anywhere in the hierarchy.
The mainline routine which controls the second-level routines are executed in order. It:
- should be short and simple (usually no more than 50 procedural statements),
- must invoke all second-level routines through PERFORM statements,
- should contain the only normal exit point of the subprogram (i.e., a GOBACK as the
last statement).
The processing routines should be broken down into as many functional levels as
necessary, depending on the complexity of the subprogram. Each routine should:
- perform a distinct function,
- have a meaningful name,
- contain only one entry point which is, the first statement in the paragraph,
- invokes only lower level routines,
- return to the higher level routine through the only one exit point.

Level 1
MAINLINE-RTNE
Mailine Routine
Level 2
A000-INIT-RTNE B000-PROC-RTNE C000-TERM-RTNE
Processing Routine
A100-INIT- A200-READ- C100-FORMT-MSG- Level 3

B100-CALC-RTNE
TABLE-RTNE FILE-RTNE RTNE Processing Routine
A110-INIT- A120-INIT- Level 4

FLD-A-RTNE FLD-B-RTNE Processing Routine
A111-INIT- Level 5
CONV-A-RTNE Processing Routine
Y100-READ- Y200-WRITE- Common

Y300-EXCPT-RTNE
REC-RTNE REC-RTNE Processing Routine
Figure 2.5 Hierarchical structure of a subprogram

2.1.5. Subroutine Structure
Each subroutine may be written in form of a paragraph or section (containing several

paragraphs), with one entry point and one exit point.
The paragraph or section must be given a meaningful name which gives an indication of
the function it performs and, if possible, indicates its physical position in the source listing
(in relation to other paragraphs/sections). A suggested format is:
Format: xxxx -a....a-RTNE - for routine

xxxx -a....a SECTION - for section
where: xxxx - is a prefix in the form of one alphabetic character followed by

a number (e.g., A120). Routines should be coded in numeric
value of prefix order so that they can be found easily in the
program listing.
a....a - meaningful abbreviations which give an indication of the

function of the routine, linked by hyphens.
2.1.6. Sequence
An important feature of well-developed program is that the program can be easily, quickly
and efficiently maintained.
Source code is the most important piece of documentation about program. Therefore, it
must be well structured, well documented (refer to section 2.2) and, above all, easy to
understand.
Each main program and subprogram should be laid out in such a way that it is easy to
locate any piece of code.
In the WORKING-STORAGE SECTION, the data structure definitions of file records

should appear in same sequence as their associated files are defined in the FILE
SECTION.
To increase efficiency:
• the most frequently referenced data items should be placed at the beginning
of Working-Storage
• data names of constant value should be grouped together

• data names whose values vary during execution should also be grouped
together and should be separated from those of constant value.
Within the PROCEDURE DIVISION, the structure of the program must be reflected in the
code. That is, routines (ie, paragraphs) should be ordered in such a way that each routine
follows its associated PERFORM statement.
Note: Since a routine frequently contains several PERFORMs, writing a PERFORMed

routine after the invoking routine means 'somewhere after', not necessarily
'immediately after'.
The common routines, which are PERFORMed by many other routines, should appear
near the end of the source code.
The correct sequence of routines in the source code is illustrated in Figure 2.6.
The mainline routine at the top of the hierarchy (MAINLINE) appears first in the source
code. This is followed by the first level-2 routine invoked (A00-INIT-RTNE), which in
turn is followed by the level-3 routine invoked (A110-INIT-FLD-A-RTNE), etc.
At the end of the source code are the three common routines (Y100-READ-WRITE-
RTNE, Y200-WRITE-REC-RTNE and Y30-EXCPT-RTNE).
For efficiency, all frequently used routines should be grouped together, apart from
infrequently used routines.

HIERARCHICAL STRUCTURE
Level 1
MAINLINE-RTNE
Mailine Routine
Level 2
A000-INIT-RTNE B000-PROC-RTNE C000-TERM-RTNE
Processing Routine
A100-INIT- A200-READ- C100-FORMT-MSG- Level 3

B100-CALC-RTNE
TABLE-RTNE FILE-RTNE RTNE Processing Routine
A110-INIT- A120-INIT- Level 4

FLD-A-RTNE FLD-B-RTNE Processing Routine
A111-INIT- Level 5
CONV-A-RTNE Processing Routine
Y100-READ- Y200-WRITE- Common

Y300-EXCPT-RTNE
REC-RTNE REC-RTNE Processing Routine
Source Code

Figure 2.6 Sequence of routines in source code

2.1.7. Spacing and new page
Either EJECT statement or a slash “/” (which both force page breaks) should be used
liberally to bring out the structure of the program and to make it easier to read. It is
recommended that the EJECT statement or a slash should be defined previous to following
parts:
• Divisions
• File Descriptions (FD) and Sort Descriptions (SD) statements
• Significant groupings in Working-Storage
• Procedure Division routines
Each logical set of instructions should be followed by at least one blank line or one empty
comment.
Comments and procedural code should be followed by at least one blank line or one empty
comment.
Only one procedural statement should be coded on each line.
Although both EJECT statements or a slash “/” can be used for spacing and new page,
don’t intermix them in a program as it will introduce confusion.
2.1.8. Indentation
Two-column indentation is recommended to be used to show the hierarchical structure of

related data items as shown in Figure 2.7. However, different development centres are
allowed to use different standard of indentation provided that it is applied consistently.
Moreover, development centres are allowed to have their steps of the level number provide
that it is also applied consistently.
01 CUST-REC-WORK.
05 CUST-NUM PIC 9(5).
05 CUST-ADDR.
10 CUST-ADDR-1 PIC X(20).
Figure 2.7 Two columns indentation

Clauses and statements in the Procedure Division should be indented to make the logic
easier to follow and to show the levels of nesting as in Figure 2.8.
If A = ITEM-1
If B = ITEM-2
……………
……………
ELSE
……………
END-IF
ELSE
……………
END-IF
Figure 2.8 Clauses and statements in procedure division
2.1.9. Use of END-Verbs
There are many END-verbs defined in COBOL standards, as stated:
• END-ADD
• END-COMPLETE
• END-COMPUTE
• END-DIVIDE
• END-IF
• END-PERFORM
• END-READ
• END-WRITE
:
Among all END-verbs, END-IF is one of the most commonly used. END-IF should be
added after all IF clauses to terminate the scope of IF clause, for example:
IF A = 1
MOVE B TO C
ELSE
MOVE A TO C
END-IF

MOVE D TO E
All five arithmetic verbs include an END-verb scope terminator that can be used to
terminate the range of the [NOT] ON SIZE ERROR conditionals. For example, the END-
COMPUTE in the example below terminates the scope of the NOT ON SIZE ERROR
clause, whereas MOVE A TO D is execute unconditionally.
Example: with END-COMPUTE
COMPUTE A = B + C
ON SIZE ERROR
MOVE ZERO to A
END-COMPUTE
MOVE A TO D
Example: without END-COMPUTE (error-prone)
COMPUTE A = B + C
ON SIZE ERROR
MOVE ZERO to A (Without/Missing a period ‘.’)
MOVE A TO D
Absence of the END-COMPUTE scope terminator results in the last statement above,
MOVE A TO D, being executed conditionally based on the ON SIZE ERROR condition,
since no period follows the statement MOVE ZERO TO A. This is so despite the deceiving
alignment of the statements in the above program segment.
In general, the END-ADD, END-SUBRACT, END-MULTIPLY, END-DIVIDE, and

END-COMPUTE are useful in defining the range of the [NOT] ON SIZE ERROR
conditions when these conditionals are included with the arithmetic verbs.
END-Verbs should be used in place of period “.” as scope terminators when there are
conditional statements (e.g. under IF or [NOT] ON SIZE ERROR) associated with the
program statement.
2.1.10. Position of source code program amendments
The COBOL compiler processes all code entered in columns 7 to 72 inclusive.

Anything entered in columns 1 to 6 or 73 to 80 is ignored but is printed on the
source listing. In general, code should be positioned in, or starting at, the
columns shown in the table below.

Column Item
1 Enhancement Identification number (**)
7 Comment symbol (*)
8 Division headers
Section headers
Paragraph headers
FD and SD statements
01 and 77 level numbers
10 05 level number
12 SELECT statementsClauses of FD/SD
statements
01 and 77 data item names
EJECT statements
Coding statements
COPY statements
36 ASSIGN, PIC, REDEFINES, VALUE
41 Comment text (see note below)
73 Enhancement Identification number (**)
Figure 2.9 Position of source code program amendments
Note: Lengthy comments (i.e., those coded at the beginning of a routine) may
start at column 12 rather than column 41.
The enhancement identification number can be placed either at column 1-

6 or column 73-80 at the moment. For the format of enhancement
identification standard, it is pending for suggestion from RBPM

2.2. Documentation
2.2.1. Overview
Documentation is an integral part of a well structured program. Narrative must be included

in code under the following categories:
• Program Documentation
• Subprogram Documentation
• Subroutine Documentation
• Comments in Code
Note that the presentation of a program is greatly enhanced (and program maintenance is
easier) if comments are coded in lower case.
2.2.2. Program Documentation
Programs must be fully documented in form of comment lines (i.e., lines of code
containing an asterisk (*) in column 7) at the beginning of main programs. The
information to be included in program documentation (most of which can be extracted
from program specification) is illustrated in Figure 2.10.

----+----1----+----2----+----3----+----4----+----5----+----6----+----7----+----8
********************************* Top of Data **********************************
IDENTIFICATION DIVISION.
PROGRAM-ID. program-name
COPY COPYRGTC REPLACING YEAR BY ccyy.
AUTHOR. author's name
INSTALLATION. HONGKONG BANK GROUP.
DATE-WRITTEN. dd/mm/ccyy
DATE-COMPILED.
*REMARKS.
*
* ABSTRACT
*
* description of the program's main functions
*
EJECT
*
*
* AMENDMENT HISTORY
*
* for each amendment made to the program (chronological
* sequence):
*
* DATE dd/mm/ccyy (amendment date)
*
* PPCR nnnnn (PPCR number)
*
* PROGRAMMER name of programmer making amendment
*
* ABSTRACT brief description of amendment
*
EJECT
*
* OPERATING INSTRUCTIONS
*
* information the operator needs to run the program
*
* 1. CONTROL CARDS
*
* JCL statements required for normal operation, plus
* parameter details (values and meanings), if required
*
* 2. FILES
*
* for each file: ddname, usage, source/destination of data,
* file organization, record types,
* dependencies
* OPTIONAL
* INPUT FILES
* input file 1
* ......
*
* INTERMEDIATE FILES
* intermediate file 1
* ......
*
* OUTPUT FILES
* output file 1
* ......
*
* 3. CONTINGENCY SETUP
*

* description of contingency procedures including:

* - whether program is to be run
* - output to be suppressed (ddnames and dataset names)
* - JCL statements required
*
* 4. PROGRAM MESSAGES
*
* for each message:
* message-id - message number and narrative
* DESTINATION - name of party for whom message is intended
* DESCRIPTION - what causes the message to be printed
* ACTION - corrective action to be taken
*
* 5. COMPLETION CODES
*
* value and meaning of every return code, plus action to
* be taken if job terminates prematurely
*
* 6. NOTES
*
* - minimum machine configuration required if h/v failure
* - actions to be taken if specific devices unavailable
* - checkpoint/restart details
* - additional information which operator may need
*
EJECT
*
* PROGRAM OPERATION
*
* pseudo code for mainline logic
*
* DATA FORMATS OPTIONAL
*
* supplementary information re: records, screens and tables
* defined in data division e.g. data item default values
*
* SUBPROGRAMS
*
* name and brief description of each invoked module
*
* module - function
* ......
*
* STORAGE LAYOUTS
*
* storage used by program - OCCUPIES xxxxK
*
* PROGRAM LIMITATIONS
*
* table sizes, etc
*
* LKED OPTIONS
*
* special link-edit options and statements required
*
EJECT
ENVIRONMENT DIVISION.
CONFIGURATION SECTION.
SOURCE-COMPUTER. IBM-370.
OBJECT-COMPUTER. IBM-370.
SPECIAL-NAMES.
C01 IS SKIP-TO-NEW-PAGE
CONSOLE IS LOG.

INPUT-OUTPUT SECTION.
FILE-CONTROL.
COPY ddname1Q.
COPY ddname2Q.
.
.
.
EJECT
DATA DIVISION.
FILE SECTION.
*
* function of file1
*
COPY ddname1F.
*
* function of file2
*
COPY ddname2F.
.
.
EJECT
WORKING-STORAGE SECTION.
77 FILLER PIC X(35) VALUE

'WORKING STORAGE SECTION STARTS HERE'.
.
.
.
.
'END OF WORKING STORAGE SECTION'.
EJECT
PROCEDURE DIVISION.
MAINLINE SECTION.
.
.
.
.
EJECT
.
.
.
.
EJECT
.
.
Figure 2.10 Program documentation required in the main program

2.2.3. Subprogram Documentation
Subprogram should be fully documented in section of comments (started with

*REMARKS) of the Identification Division as described earlier in the section of program
documentation.
In addition to provide a description of the subprogram’s function, the entry and exit
conditions should be documented as follows:
FUNCTION - Description of what the subprogram does.
ENTRY CONDITIONS - Description of all conditions that must be in effect at the time
when the subprogram receives control. For example:
- Calling sequence
- Parameters passed
- Files that must be open
- Common areas that must be set up.
EXIT CONDITIONS - A description of all changes that occur as a result of executing

the module. For example:
- Entry parameters altered

- Return codes set
- Files altered
- Common areas changed

----+----1----+----2----+----3----+----4----+----5----+----6----+----7----+----8
PROGRAM-ID. subprogram-name.
AUTHOR. author's name.
INSTALLATION. HONGKONG BANK GROUP.
DATE-WRITTEN. dd/mm/ccyy
DATE-COMPILED.
* REMARKS
*
* ABSTRACT
*
* FUNCTION: A description of what the subprogram does.
*
* ENTRY CONDITIONS: Details of how to invoke the subprogram,
* plus a description of all conditions which
* must pertain at the time it is called,
* for example:
*
* - calling sequence
* - parameters passed
* - flags which must be set
* - files that must be open
* - common areas that must be set up
*
* EXIT CONDITIONS : A description of everything external to
* the subprogram which may be changed as a
* result of executing it, for example:
*
* - entry parameters altered
* - return codes set
* - files altered
* - common areas changed
EJECT
Figure 2.11 Program documentation required in the subprogram
2.2.4. Subroutine Documentation
Documentation should be provided in the form of comment lines at the beginning of each
routine (i.e., paragraph) in the program. The information to be included is illustrated
below.

----+----1----+----2----+----3----+----4----+----5----+----6----+----7----+----8
EJECT
subname-RTNE.
*
* FUNCTION - Details of what the routine does
* How it is called
* Parameters passed
* Anything unusual about the routine
* Return codes set, etc.
*
.
. subroutine coding
.
Figure 2.12 Subroutine documentation
2.2.5. Comments in code
Use comments extensively to explain the processing and purpose of sections of code.
The three reasons for including them are:
• To explain the functional processes that the program is performing

• To explain complex code logic step by step
• To explain any special processing that is used, where significance of a
statement cannot be deduced from the logic of the code (e.g. setting a field to
a special value).
All sections of code should be easy to understand. COBOL allows variable names and
section names of up to thirty characters in length, so these can be made reasonably
“standard English”. If there is any possibility of confusion then a comment block must be
included to make things clearer.
One blank line or one empty comment line should be used to separate the comments
imbedded in code from the instructions. For example:
----+----1----+----2----+----3----+----4----+----5----+----6----+----7----+----8
* If account has been inactive for more than 24 months, *
* write details to Statistics File *
IF WS-ACCOUNT INACTIVE
PERFORM C111-WRITE-STAT-RTNE
THRU C111-WRITE-STAT-EXIT
END-IF.
Figure 2.13 Comments in code

2.3. Macro Copybooks
2.3.1. Data Macros
The following standards apply to all data macros:
• Use PIC rather than PICTURE.

• Use COMP rather than COMPUTATIONAL or BINARY.
• Use COMP-3 rather than COMPUTATIONAL-3 or PACKED-DECIMAL.
• Use FILLER rather than F.
• Use VALUE rather than VALUE IS.
• Avoid use of USAGE.
• Use two columns indentation to show the hierarchical structure of related data
items.
• Code macros containing 'ASSIGN TO ...' clauses in one of the formats
illustrated in Figure 2.15.
• Code macros containing FD or SD statements in one of the formats illustrated
in Figure 2.16.
• Code macros containing data structure definition (DSD) statements in the
format shown in Figure 2.17.
• For macros containing DSD statements (Figure 2.15), code a separate 01 and
05 level for each record or transaction type and name each data item as
follows:
01 level - mmmmmmm-WORK
05 level - mmmmmmm-WORK-REC-xx
other levels - mmmmmmm-a....a
where:
mmmmmmm -macro name minus final character. (For the macro naming
conventions, please refer to COBOL Coding Practice in
details)
xx - numeric or mnemonic record/transaction identifier (not needed

if only one record/transaction type).
a....a - one or more abbreviations linked by hyphens. Each
abbreviation must have an entry in the Group Metadata
Repository (GMR) Glossary (Figure 2.14).
Three examples of data macros are shown in Figure 2.18.


Figure 2.14 Use abbreviations defined in Group Metadata Repository (GMR) Glossary

Data Macros Containing ‘ASSIGN TO ….’ Clause
1. Non-VSAM Sequential Files

SELECT XXXXXXXX ASSIGN TO UT-S-XXXXXXXX.
2. VSAM Sequential Files

SELECT XXXXXXXX ASSIGN TO AS-XXXXXXXX.
3. VSAM Indexed Files

SELECT xxxxxxxx ASSIGN TO xxxxxxxx
ORGANIZATION IS INDEXED
< SEQUENTIAL >
ACCESS IS < RANDOM >
< DYNAMIC >
RECORD KEY IS mmmmmmm-REC-zzz-KEY
[ALTERNATE RECORD KEY IS mmmmmmm-ALT-REC-zzz-KEY-n]
FILE STATUS IS xxxxxxxx-STUS
KEY:xxxxxxxx – ddname assigned to the file

mmmmmmm - macro name minus last character
zzz – IN, OUT or UPD
n - path number
Note: The ddname of alternate index is xxxxxxxxn, and the format of an alternate path
is a …. An, where a…..a is the full dataset name and n is the path number.
Figure 2.15 Format of macros containing ‘ASSIGN TO …’ clause

Data Macros Containing FD or SD Statements
1. Without Key
FD mmmmmmm
RECORD CONTAINS …
BLOCK CONTAINS x RECORDS
LABEL RECORDS …
DATA RECORD IS …
*
* comments
*
01 mmmmmmm-REC-zzz-nn.
05 FILLER PIC X(r1)
2. With Key
FD mmmmmmm
RECORD CONTAINS …
BLOCK CONTAINS x RECORDS
LABEL RECORDS …
DATA RECORD IS …
*
* comments
*
01 mmmmmmm-REC-zzz-nn.
05 mmmmmmm-REC-zzz-nn-KEY PIC X(k1)

*
* comments
*
05 FILLER PIC X(r1-k1)
KEY: x – is (normally) non-zero – ISAM file

0 - other file
mmmmmmm - macro name minus last character (i.e., F)

zzz – IN, OUT or UPD
nn - record identifier, 01-99 (not needed if only 1 record type)
Note: The format of a data item name containing the number of times a record is
repeated in an ‘OCCURS .. DEPENDING ON ..’ clause (if present) is mmmmmmm-LNG-
nn.
Figure 2.16 Format of macros containing FD or SD statements

Data Macros Containing Data Structure Definition Statements (Records and Common Areas)
*
* comments
*
05 mmmmmmm-WORK-REC-nn.
*
* comments
*
10 mmmmmmm-a….a.
R
15 mmmmmmm-a….a. PIC …
15 mmmmmmm-a….a. PIC …
:
:
*
* comments
*
05 mmmmmmm-WORK-REC-nn REDEFINES
KEY:
mmmmmmm - macro name minus last character (i.e., the W). (For the naming
conventions, please refer to COBOL Coding Practice in details)
nn - unique record/transaction identifier, 01-99 (not required if only one

record/transaction type.
a….a - one or more meaningful abbreviations linked by hyphens

R - repeated for each record/transaction type.
Figure 2.17 Format of macros containing data structure definition statements

1. Macro Containing ‘ASSIGN TO’ Clause
Name Contents of Data Macro

CARDIQ SELECT CARDI ASSIGN TO UT-S-CARDI
2. Macro Containing File Description (FD) Statements

CARDIF FD CARDI
RECORD CONTAINS 80 CHARACTERS
BLOCK CONTAIN 0 RECORDS
LABEL RECORDS ARE OMITTED
DATA RECORD IS CARD-REC-IN
*
* Comments
*
01 CARD-REC-IN.
05 FILLER PIC X(80).
3. Macro Containing Data Structure Definition

Statements

CARDW *
* Comments
*
05 CARD-WORK-REC.
10 CARD-CUST-ID PIC X(12).
10 FILLER PIC X.
10 CARD-INSTT-ID PIC X(4).
10 FILLER PIC X.
10 CARD-DVSN-ID PIC X(3).
10 FILLER PIC X(59).
The data macros above contain the file and data

structure definition statements for a file with
ddname CARDI.
Figure 2.18 Three examples of data macros

2.3.2. Procedure Coding Macros
Using procedure coding macro is a means to allow code customization on global / vendor
base code. The global / vendor base code can specify the inclusion of a piece of coding to
be provided by customer codes by copying a coding macro. This retains the base code
version unchanged while the processing logics can be tailored to suit the customization
need by different pieces of codes. For details on program change management, please
refer to Coding Practice section.
Advantages of procedure coding macros:
• Minimizes the changes in vendor base code

• Reduces the amount of retrofitting required when taking new releases and
fixes from the vendor
• Provides a object oriented method for developing specific business needs
without impacting multiple businesses
When implemented by the business units, it provides a quick and efficient way to move
profitable localized enhancements to the Global level and distribute globally.
In the procedure coding macros, only single function or similar functions paragraphs
should be covered in one procedure coding macro.

2.4. Program Divisions Coding Rules
2.4.1. General Coding Standards
• IBM-only features
The IBM COBOL compiler is fully compatible with the highest level of American
National Standards Institute (ANSI) COBOL. It also includes a number of IBM
extensions, some of which represent features not approved by ANSI COBOL.
In order to confine the use of COBOL to ANSI standard, normally, only those
IBM extensions that appear in the following list may be included in programs.
The use of any other IBM-only feature must have the approval of the Project
Manager.
• USAGE IS COMP-3
• CONSOLE IS LOG
• ENTRY literal-1 [USING identifier-1 identifier-2 .....]
• EXIT PROGRAM
• GOBACK
• EXHIBIT
• READY TRACE
• RESET TRACE
• EJECT
• *
• CURRENT-DATE
• UPSI-n
• SELECT filename COPY statement
• COBOL words and statements
1. Use PIC instead of PICTURE

2. Use COMP instead of COMPUTATIONAL or BINARY
3. Use COMP-3 instead of COMPUTATIONAL-3 or PACKED-DECIMAL
4. Use FILLER instead of F
5. Use VALUE rather than VALUE IS
6. Avoid the use of USAGE
7. Never use RENAME
8. Never use the ALTER statement

2.4.2. Identification Division Coding Rules
The Identification Division must begin on a new page.
As mentioned in the Documentation section, the following must be present in the order
given, separated by blank lines or empty comment lines.
• PROGRAM-ID
• Copyright statement.
• AUTHOR
• INSTALLATION
• DATE-WRITTEN
• DATE-COMPILED
• Copyright statement
Include the macro 'COPYRGTC' after the program name to generate the
'Copyright' clause. The format of the 'COPY' statement and the generated
clause is shown as below:
----+----1----+----2----+----3----+----4----+----5----+----6----+----7----+----8
PROGRAM-ID progname

*************************************************************
* COPYRIGHT. *
* THE HONGKONG AND SHANGHAI BANKING CORPORATION LIMITED *
* ccyy. ALL RIGHTS RESERVED. *
* *
* THIS SOFTWARE IS ONLY TO BE USED FOR THE PURPOSE FOR WHICH*
* IT HAS BEEN PROVIDED. NO PART OF IT IS TO BE REPRODUCED, *
* DISASSEMBLED, TRANSMITTED, STORED IN A RETRIEVAL SYSTEM, *
* NOR TRANSLATED IN ANY HUMAN OR COMPUTER LANGUAGE IN ANY *
* WAY OR FOR ANY OTHER PURPOSES WHATSOEVER WITHOUT THE PRIOR*
* WRITTEN CONSENT OF THE HONGKONG AND SHANGHAI BANKING *
* CORPORATION LIMITED. INFRINGEMENT OF COPYRIGHT IS A *
* SERIOUS CIVIL AND CRIMINAL OFFENCE, WHICH CAN RESULT IN *
* HEAVY FINES AND PAYMENT OF SUBSTANTIAL DAMAGES. *
*************************************************************
Figure 2.19 Example of Copyright statement
• Remark Section
Document the program at the end of Identification Division in the Remarks section
(group of comment lines started with “*REMARKS”), as described and illustrated
earlier in the section.

2.4.3. Environment Division Coding Rules
• Division layout
The Environment Division should be coded in the format shown below:
----+----1----+----2----+----3----+----4----+----5----+----6----+----7----+----8
ENVIRONMENT DIVISION.
CONFIGURATION SECTION.
OBJECT-COMPUTER. objectname.
SOURCE-COMPUTER. sourcename.
SPECIAL-NAMES.
C01 IS SKIP-TO-NEW-PAGE.
CONSOLE IS LOG.
INPUT-OUTPUT SECTION.
FILE-CONTROL.
COPY ddname1Q.
COPY ddname2Q.
Figure 2.20 Example of Environment Division
Note:
1. Make sure the division header is spelt correctly and without hyphen, the
necessary periods are included, and the hyphens are in the correct place in the
other headers and keywords.
• Special Names
Define the following mnemonic-names in the Special-Names paragraph and use them
throughout program, in order to provide better documentation, in place of the
corresponding IBM function-names:
Function-name Mnemonic-name
C01 IS SKIP-TO-NEW-PAGE
CONSOLE IS LOG

• Input/Output
Use 'COPY' statements to obtain pre-written 'SELECT …ASSIGN TO ...' clauses

from a macro in library. Do not hard code these clauses.
If asked to set up macro (for a new file), follow the instructions presented earlier in
this section. Two I/O areas should be used for every dataset defined.
Either code RESERVE 1 ALTERNATE AREA or omit the RESERVE clause.
2.4.4. Data Division Coding Rules
• Division layout
The Data Division should be coded in the format shown below:
DATA DIVISION.
FILE SECTION.
* function of file1
COPY ddname1F.
* function of file1
COPY ddname2F.
EJECT
WORKING-STORAGE SECTION.

'WORKING STORAGE SECTION STARTS HERE'.
*01 recname1.
COPY macname1.
*01 recname2.
COPY macname2.
.
.
.
'END OF WORKING STORAGE SECTION'.
EJECT
LINKAGE SECTION.
.
Figure 2.21 Example of data division
Note:
1. Make sure the division header is spelt correctly and without hyphen, the
required periods are included, the hyphen is in a correct place in 'WORKING-
STORAGE'.
2. Each data item definition statement must be terminated by a period.

• File Section
'COPY' statements must be used to obtain pre-written FD and SD statements, and

associated record description entries, from a macro in library. The statements must
not be hard coded in the program.
• Working Storage Section
a. Code a level 77 data item, with the value indicated below, as the first entry in the
Working-Storage section:
"WORKING STORAGE SECTION STARTS HERE"
Also code a level 77 data item, with the value given below, at the very end of the
Working-Storage section:
"END OF WORKING STORAGE SECTION"
These two items will help you to find the beginning and end of Working-Storage
in an MVS memory dump.
b. For efficiency:
- place the most frequently referenced data items at the beginning of the section
- group data names of constant value together, and apart from those whose
values vary during execution.
c. Define all literals that may change in Working-Storage. Examples are:
- size and number of items in a table

- error messages
- line counts to control form skipping.
Give each item a meaningful name that conforms to the standards laid down for
data item names.
Assign date related data items a name according to the standards for data items
defined in data macros (these are described in Section 2.3.1).
d. Define all tables with the 'INDEXED BY' option.

e. Define condition-names that are concise and self-explanatory as shown in Figure

2.22:
05 WS-MARITAL-STATUS PIC 9.
88 WS-MARITAL-MARRIED VALUE 1.
88 WS-MARITAL-SINGLE VALUE 2.
88 WS-MARITAL-DIVORCED VALUE 3.
88 WS-MARITAL-WIDOWED VALUE 4.
Figure 2.22 Example of condition-names
The type of literal in a condition entry must be consistent with the data type of
the conditional variable, otherwise it will be flagged in error. In the above
example, if WS-MARITAL-STATUS is changed to PIC X, then all 88-level
condition entries must be changed to alphanumeric literals ("1","2", "3", "4").
f. Initialize all data items using the VALUE clause. The VALUE clause defines the
initial state of a program only. After sub-program is called from the main
program, data value should be setup by using SET clause or MOVE clause to
make sure a latest value is maintained.
g. Use the 'COPY' statement to obtain pre-written record description (data structure
definition) statements from a macro in library. Do not hardcode these statements
in programs.
h. Use “PSEUDO TEXT” approach in copybook to keep the flexibility to change

the prefix or field name.
For example:
In COPYBOOK, macro FILEAW is defined as:
01 “prefix”-REC
05 “prefix”-REC-TYPE PIC X.
88 “prefix”-REC-HEADER VALUE ‘H’.
88 “prefix”-REC-FOOTER VALUE ‘F’.
05 “prefix”-REC-NO PIC 9(3).
If a file B’s layout is the same as file A, then the macro can be re-used by using
the copy replacing method to replace “prefix” by FILEB.

2.4.5. Procedure Division Coding Rules
2.4.5.1. Division layout
The Procedure Division should be organized into at least 3 functional levels:

1. Mainline Routine
2. Processing Routines
3. Common Routines (e.g., input and output routines)
Mainline Routine
Controls second-level routines in order. It should:
- be short and simple (usually no more than 50 statements)
- define overall flow of program logic and contain major logical decisions
- invoke all second-level processing routines by PERFORM statements.
Processing Routines
These routines should be broken down into as many functional levels as necessary,
depending on complexity of program. Each routine should:
- have a meaningful name
- contain only one entry point which is the first statement in the routine
- contain only one exit point, which should be the last statement in the routine
- perform a distinct function
- invoke only lower level routines
- return to higher level routine after the last statement in the routine
For performance reasons, all frequently used routines should be placed near the
routines that use them.
Common Routines
These routines should be the lowest level routines since all higher level routines have
access to them. Frequently executed routines (e.g., input and output routines) should
be grouped together.
Infrequently executed routines (e.g., error handling) should also be grouped

together, apart from frequently used routines.
There should be only one functional read or write routine for each file, which is
frequently accessed.
Common routines should:

- have meaningful names
- contain only one entry point (the first statement in the routine), and one exit
point (the last statement in the routine)

2.4.5.2. Short Routines
Do not use too many trivial routines that contains only one or two lines as they:
- increase the size of programs (several bytes used each time a new routine is
invoked)
- make program logic difficult to follow.
It is far better to code several small routines that are functionally related together,
e.g., one routine to open files and check status.
2.4.5.3. Routine Name/Entry and Exit Points
A routine may be written either in form of a subroutine or as a section.
In either case, each routine must have one entry point and one exit point with names
in following format:
a. Entry Point
sname-RTNE - subroutine
sname SECTION - section
b. Exit Point
The last statement of a routine is the exit point of the routine.
The routine name should give an indication of function which it performs

and, if possible, indicate its physical position (in relation to other subroutines)
in program listing.
A suggested format for a routine name is: xxxx-a....a
where:
xxxx - is a prefix in form of one alphabetic character followed by a number (e.g.,
C100). Subroutines should be coded in prefix order so that they can be
located easily in program listing.
a....a - one or more abbreviations giving an indication of function of the routine.
The above naming conventions are illustrated in Figure 2.23 to Figure 2.24.

Figure 2.23 shows a hierarchical structure of Program A, which comprises a mainline

routine, three levels of processing routines and two common routines are called by
several non-common routines.
MAINLINE-RTNE Level 1
A000-INIT-RTNE B000-PROC-RTNE C000-TERM-RTNE Level 2
A100-INIT- A200-READ- C100-FORMT-MSG-

B100-CALC-RTNE Level 3
TABLE-RTNE FILE-RTNE RTNE
A110-INIT- A120-INIT-
Level 4
FLD-A-RTNE FLD-B-RTNE
A111-INIT-
Level 5
CONV-A-RTNE
Y100-READ- Y200-WRITE- Common Routine

Y300-EXCPT-RTNE
REC-RTNE REC-RTNE
Figure 2.23 Example of a program hierarchy chart

----+----1----+----2----+----3----+----4----+----5----+----6----+----7----+----8
PROCEDURE DIVISION.
MAINLINE SECTION.
PERFORM A000--INIT-RTNE
THRU A000-INIT-EXIT.
PERFORM B000-PROC-RTNE
THRU B000-PROC-EXIT.
PERFORM C000-TERM-RTNE
THRU C000-TERM-EXIT.
MAINLINE-EXIT.
GOBACK.
----+----1----+----2----+----3----+----4----+----5----+----6----+----7----+----8
* SUBROUTINE - INITIALIZATION ROUTINE
* REMARKS - OPEN FILES A, B
*
A000-INIT-RTNE.
PERFORM A100-INIT-TABLE-RTNE
THRU A100-INIT-TABLE-EXIT.
PERFORM A200-READ-FILE-RTNE
THRU A200-READ-FILE-EXIT.
A000-INIT-EXIT.
EXIT.
----+----1----+----2----+----3----+----4----+----5----+----6----+----7----+----8
* SUBROUTINE - INITIALIZATION TABLE ROUTINE
* REMARKS - INITIALIZE TABLES USED IN THE PROGRAM
*
A100-INIT-TABLE-RTNE.
PERFORM A110-INIT-FLD-A-RTNE
THRU A110-INIT-FLD-A-EXIT.
PERFORM A120-INIT-FLD-B-RTNE
THRU A120-INIT-FLD-B-EXIT.
A100-INIT-TABLE-EXIT.
EXIT.
----+----1----+----2----+----3----+----4----+----5----+----6----+----7----+----8
* SUBROUTINE - INITIALIZATION FIELDS A ROUTINE
* REMARKS - INITIALIZE ALL FIELDS USED FOR FILE A
*
A110-INIT-FLD-A-RTNE.
.
.
PERFORM A110-INIT-CONV-A-RTNE
THRU A110-INIT-CONV-A-EXIT.
.
.
A110-INIT-FLD-A-EXIT.
EXIT.

----+----1----+----2----+----3----+----4----+----5----+----6----+----7----+----8
* SUBROUTINE - INITIALIZATION CONVERTED FIELDS A ROUTINE
* REMARKS - INITIALIZE ALL CONVERTED FIELDS USED FOR FILE A
*
A111-INIT-CONV-A-RTNE.
.
.
.
A111-INIT-CONV-A-EXIT.
EXIT.
----+----1----+----2----+----3----+----4----+----5----+----6----+----7----+----8
* SUBROUTINE - INITIALIZATION FIELDS B ROUTINE
* REMARKS - INITIALIZE ALL FIELDS USED FOR FILE B
*
A120-INIT-FLD-B-RTNE.
.
.
.
A120-INIT-FLD-B-EXIT.
EXIT.
----+----1----+----2----+----3----+----4----+----5----+----6----+----7----+----8
* SUBROUTINE - READ FILE ROUTINE
* REMARKS - READ FILES
*
A200-READ-FILE-RTNE.
.
.
.
A200-READ-FILE-EXIT.
EXIT.
----+----1----+----2----+----3----+----4----+----5----+----6----+----7----+----8
* SUBROUTINE - PROCESS ROUTINE
* REMARKS - PROCESSING DATA
*
B000-PROC-RTNE.
...
PERFORM B100-CALC-RTNE
THRU B100-CALC-EXIT.
...
B000-PROC-EXIT.
EXIT.
----+----1----+----2----+----3----+----4----+----5----+----6----+----7----+----8
* SUBROUTINE - CALCULATION ROUTINE
* REMARKS - DO CALCUATION FOR THE DATA
*
B100-CALC-RTNE.
.
.
.
B100-CALC-EXIT.
EXIT.
----+----1----+----2----+----3----+----4----+----5----+----6----+----7----+----8
* SUBROUTINE - TERMINATION ROUTINE
* REMARKS - HANDLE THE ACTION BEFORE PROGRAM TERMINATE
*
C000-TERM-RTNE.
...
PERFORM C100-FORMT-MSG-RTNE
THRU C100-FORMT-MSG-EXIT.

...
C000-TERM-EXIT.
EXIT.

----+----1----+----2----+----3----+----4----+----5----+----6----+----7----+----8
* SUBROUTINE - FORMAT MESSAGE ROUTINE
* REMARKS - FORMAT MESSAGE USED IN THE PROGRAM
*
C100-FORMT-MSG-RTNE.
.
.
.
C100-FORMT-MSG-EXIT.
EXIT.
----+----1----+----2----+----3----+----4----+----5----+----6----+----7----+----8
* SUBROUTINE - READ RECORD ROUTINE
* REMARKS - READ RECORDS FROM TARGET FILE TO SAVE AREA
*
Y100-READ-REC-RTNE.
.
.
.
Y100-READ-REC-EXIT.
EXIT.
----+----1----+----2----+----3----+----4----+----5----+----6----+----7----+----8
* SUBROUTINE - WRITE RECORD ROUTINE
* REMARKS - WRITE RECORDS FROM SAVE AREA TO TARGET FILE
*
Y200-WRITE-REC-RTNE.
.
.
.
Y200-WRITE-REC-EXIT.
EXIT.
----+----1----+----2----+----3----+----4----+----5----+----6----+----7----+----8
* SUBROUTINE - EXCEPTIONAL ROUTINE
* REMARKS - HANDLE PROGRAM EXCEPTIONAL SITUATION
*
Y300-EXCPT-RTNE.
.
.
.
Y300-EXCPT-EXIT.
EXIT.
Figure 2.24 Procedure division of a program
2.4.5.4. Opening/closing files
There should be one OPEN file routine and one CLOSE file routine for a program
and, where possible, all files should be opened in one statement and closed in one
statement.

Opening (closing) more than one file in same statement is faster than using a separate
statement for each.
All files should be closed before the program is terminated.
2.4.5.5. Routine Name/Entry and Exit Points
All routines must be invoked by the PERFORM statement. The following rules must
be adhered to:
- Always invoke a routine by using PERFORM sname-RTNE THRU sname-EXIT

to make sure the whole routine is run before complete the PERFROM action. If
GO TO statement is used, it must jump to routine exit, i.e. sname-EXIT. Refer to
section 2.4.5.6 for detailed discussion of PERFORM THRU statement.
2.4.5.6. PERFORM … THRU …
‘PERFORM… THRU …’ statement is a common COBOL syntax. This clause

always use with routine exit to make sure the whole routine is run before return to
upper level of the program.
For example:
B000-PROC-RTNE.
.
.
.
PERFORM B100-CALC-RTNE
THRU B100-CALC-EXIT.
.
.
.
B000-PROC-EXIT.
EXIT.
2.4.5.7. Input/Output of data

- Perform initial read of all input files in initialization routine. Check for empty
files and missing header records condition before entering the processing
routine.
- Perform data manipulation on a data defined in the Working-Storage Section,

but not in the File Section, i.e.,
a. use "READ INTO....." option to access a record in input buffer and

move it to a Working-Storage area
b. process the record in Working-Storage
c. use "WRITE FROM....." option to move the record from the Working-
Storage area to output buffer before releasing it to output file.
This is suggested for three reasons:
- Debugging is much simpler as working-storage areas are easier to locate

in a dump than buffer areas
- Attempting to access a record after 'AT END' condition has occurred can
cause problems if the record area is only in File Section
- “WRITE FROM…” allows multiple writes of same record.
- Code end-of-file conditions for all files.
- Cater for all possible return code values.
2.4.5.8. Conditional statements
1. 'IF' statements
Do not use more than three levels of nested IF statements. Use EVALUATE
instead for conditional determination. For example:
EVALUATE variable-a
WHEN 'A'
PERFORM C111-A-RTNE
THRU C111-A-EXIT
WHEN 'B'
PERFORM C112-B-RTNE
THRU C112-B-EXIT
WHEN 'C'
PERFORM C113-C-RTNE
THRU C113-C-EXIT

WHEN 'D'
PERFORM C114-D-RTNE
THRU C114-D-EXIT
WHEN OTHER
PERFORM C115-E-RTNE
THRU C115-E-EXIT
END-EVALUATE
2. Comparison statement
For program clarity and readability, the comparison symbols ‘>’ ‘<’, ‘>=’,
‘<=’, ‘=’ are more preferable to corresponding full words comparison
operators GREATER THAN, LESS THAN, NOT LESS THAN, etc.
3. Logical statement
Avoid using double negative conditions in logical statements.

Example:
Incorrect usage:
IF NOT MARITIAL-STATUS-NOT-MARRIED
ADD 1 TO MARRIED-CNT
END-IF
Correct usage:
IF MARITIAL-STATUS-MARRIED
ADD 1 TO MARRIED-CNT
END-IF
where
05 MARITAL-STATUS PIC X(1).
88 MARITIAL-STATUS-MARRIED VALUE '0'.
88 MARITIAL-STATIS-NOT-MARRIED VALUE '1'.
Note: Assume only two status values defined for marital status.
4. 'GO TO' statement
Minimize number of use of 'GO TO' statement, by using the 'ELSE' clause to
express alternative actions. For example:

Example: Incorrect use of ‘GO TO’:
READ-RTNE.
:
:
IF condition-1
action-1
GO TO READ-EXIT
END-IF.
action-2.
READ-EXIT.
EXIT.
Example: Enhanced version without using ‘GO TO’
READ-RTNE.
:
:
IF condition-1
action-1
ELSE
action-2
END-IF.
:
:
READ-EXIT.
EXIT.
Never use 'GO TO' to pass control to a statement outside the subroutine (or
section).
2.4.5.9. Table handling
Use indexing for table searching. The use of index-names in referencing tables is
more efficient than the use of subscripts. The use of direct indexes is faster than the
use of relative indexes.
When using tables, the followings should be done where possible:

- If a table field is used three or more times, it should be moved to a work area
instead.
- Tables should normally be indexed, but not subscripted.
- If a large table is being processed, an index must be used, unless the use of an
index greatly increases the complexity.

If index is always the same value, use:
IF WT-COUNT(1) = WC-MAXIMUM
not
SET WI-INDEX TO 1
IF WT-COUNT(WI-INDEX) = WC-MAXIMUM
If index is a variable, use;
SET WI-INDEX TO WA-VALUE

IF WT-COUNT(WI-INDEX) = WC-MAXIMUM
not
IF WT-COUNT(WA-VALUE) = WC-MAXIMUM
Please note, as stated in previous example, WI-INDEX is always defined as a

variable and as the index of the table while WA-VALUE is always defined as a
constant in the table handling.
Use SEARCH if table has 50 or fewer entries. If the table is sorted and contains over
50 entries, SEARCH ALL may be faster. Always put the most frequently hit entries
at the beginning of a table with any size, if possible, use the SEARCH statement.

2.4.5.10. Moves
When moving fields, the following should be done where possible:

- Both fields in a ‘Move’ statement have the same USAGE.
- In an alphanumeric MOVE, the receiving field length should equal the
sending field length if possible, or else the receiving field should be longer;
truncation may be avoided on a MOVE.
- COMP fields (except COMP-3) should be word aligned. (To make sure the
fields are word aligned, we may use SYNCHRONIZED clause to make the
synchronized items aligned start on a full-word boundary.)
- Numeric fields should have the same decimal alignment.
- Conversion should be avoided as much as possible.
- Check the length of two data items are in same length. Otherwise, truncation
may be induced.
If a display field is to be moved to two packed fields, the following should be coded:
MOVE UNPACK1 TO PACK1
MOVE PACK1 TO PACK2
2.4.5.11. EVALUATE
An EVALUATE should be considered if the construct would require more than three
IF statements.
EVALUATE statement should be structured so that the most likely event occurs first.
For example:
EVALUATE variable-a ALSO variable-b

WHEN 'A' ALSO ANY
PERFORM C111-A-RTNE
THRU C111-A-EXIT
EVALUATE return-value-a
WHEN ‘1’
PERFORM C114-A-RTNE
THRU C114-A-EXIT
WHEN OTHER
PERFORM C115-A-RTNE
THRU C115-A-EXIT WHEN 'B'
ALSO ANY
PERFORM C112-B-RTNE
THRU C112-B-EXIT
WHEN 'C' ALSO ‘X’

PERFORM C113-C-RTNE
THRU C113-C-EXIT
WHEN OTHER
PERFORM C114-D-RTNE
THRU C114-D-EXIT
END-EVALUATE
2.4.5.12. STRING/UNSTRING
STRING and UNSTRING should be used sparingly. If used, a comment should be

included explaining its usage.
Both are time-consuming verb because it invokes a complex subroutine. You may
use a character-by-character MOVE loop to replace STRING while it is more
efficient.
2.4.5.13. Using Literals
Use literals in Procedure Division only when the value of the literal is fixed and
guaranteed never to change. For example: 1 to increment a count, 12 to represent the
number of months in a year, 'Y' and 'N' to represent 'yes' and 'no'.
2.4.5.14. Arithmetic Operations
Use ADD/SUBTRACT/MULTIPLY/DIVIDE statements for calculations

involving only 2 data items/literals.
e.g., ADD 1 TO LINE-CNT.
Use the COMPUTE statement for all arithmetic calculations involving more than 2
data items/literals.
e.g., COMPUTE INTEREST = PRINCIPAL * INT-RATE / 1200.
The COMPUTE statement generates more efficient coding than using individual
arithmetic statements, because the compiler can keep track of internal work areas and
does not have to store the results of intermediate calculations.
Define all fields used in a computation as COMP-3.

2.4.5.15. Field Comparison
When comparing fields, the following should be ensured where possible:
- Both fields have the same USAGE.

- Length of alphanumeric fields are equal.
- Numerical fields have the same decimal alignment.
Signed display fields should not be compared with alphanumeric fields.
2.4.5.16. Program Termination
1. Always use one ‘GOBACK statement to return control to calling module,

program or operating system. Do not use 'STOP RUN'. The use of the
'GOBACK' statement allows any COBOL program to function either as a
main program or as a subprogram (module).
2. In the program termination, display a message with input and output record
counts. This message should be an “information only” message. The message
format can be referred to section 2.5.3

2.5. Program Interfaces
2.5.1. Processing External Data
• DB2
COBOL/370 supports processing of DB2. To communicate with DB2, we should:
o delimit SQL statements to access DB2

o declare the tables that you use
o declare the host variables
o declare SQL Communication Area (SQLCA)
o Handle DB2 exception conditions
• File Types Supported
COBOL/370 supports processing of QSAM and VSAM files only (it does not
support ISAM and BDAM files).
QSAM
With COBOL/370, file record length for a QSAM file must match that specified in
the program.
Mismatches in attributes for file organization, record format (fixed or variable), code
set, or record length cause the OPEN statement to fail with a file status code of 39.
VSAM
With COBOL/370, RECORDSIZE defined in VSAM files associated with IDCAMS
must match with the program.
For all files, status key must be checked after each OPEN statement.
• Input Output Statements
Data manipulation should be performed on a data that is defined in the Working-

Storage Section, but not in the File Section, i.e.,
Use 'READ INTO' option to access a record in input buffer and move it to a
Working-Storage area, process the record in Working-Storage, use the 'WRITE
FROM' option to move the record from the Working-Storage area to output buffer
before releasing it to output file.
The above comments are suggested for three reasons:

1. Debugging is much simpler since Working-Storage areas are easier to locate

in a dump than buffer areas.
2. Attempting to access a record after the 'AT END' condition, which has
occurred, can cause problems if the record area is only in File Section.
3. 'WRITE FROM' allows multiple writes of the same record.
• Closing Files
All files must be closed before the program is terminated. The file status key must be
checked after each CLOSE statement.
2.5.2. Intercommunication between Programs
This subsection describes the methods that enable inter-program communication between
separately compiled programs.
It also describes how inter-program communication can be achieved using structured

programming techniques, by 'nesting' programs inside each other.
• Transferring Control to Another Program
A program can transfer control to another program (usually called a subprogram in

COBOL/370) using a CALL statement. The called program may in turn call another
program, and so forth.
The program that calls another program is referred to as 'calling program' and the
program it calls is referred to as 'called program'.
When processing in the called program is completed, control is returned to the

calling program. In an LE/370 environment, the first COBOL program in run unit is
considered to be the 'main program', and all other COBOL programs in the run-unit
are 'subprograms'.
• Calling Subprograms
Any of the following methods can be used to transfer control from one COBOL/370
program to another COBOL/370 program:
- Static calls
- Dynamic calls
- Calls to nested programs

Static and dynamic calls can also be made between COBOL/370 and VS COBOL II
programs. These calls can also be made between COBOL/370 and OS/VS COBOL
programs, in a non-CICS environment. In a CICS environment, EXEC CICS LINK
must be used to transfer control between COBOL/370 and OS/VS COBOL
programs.
Calls to nested programs allow creation of applications using structured

programming techniques. They can also be used in place of PERFORM procedures
to prevent unintentional modification of data items.
• Static and Dynamic Calls
A static call is used to invoke a separately compiled program that is link edited into
the same load module as calling program.
A dynamic call is used to invoke a separately compiled program that has been link
edited into a separate load module from calling program. The subprogram module is
loaded into storage at the first time it is called.
For more details, please refer to COBOL Coding Practice section 2.3.
Separately Compiled Programs (EXTERNAL Clause)
It is not recommended to share data items in separately compiled programs by using

the EXTERNAL clause.
2.5.3. Program Messages
• Message destinations
All program-generated messages must be written to a centralized message control

file. This file should later be printed and/or interrogated.
Program generated messages may also be routed to one, or both, of the following
destinations:
• LOG (System Console Log) must only be used for urgent messages which are
really necessary and which require immediate action from operator.
• SYSOUT (Disposition Listing) is used by messages to draw attention of IT

operation support, development or other departments.

• Message format
The format of program generated messages is as follows:
Format: xxxxxxxx.nnnt-message text
Where: xxxxxxxx: Module name (maximum 8 characters)

nnn: Message number ( 0 – 999)
t: Type of action required:

A- requires action by operator
I- information only
W- warning message
Message: Simple and concise message text, giving clear and

adequate information (maximum length 237 characters)
• Console messages
Only urgent messages which require immediate action from the operator may be
output to operator’s console.
Such messages are normally restricted to contain maximum of 60 characters, so that

the whole message may appear in one line of console. However, where a 60-
character message would not provide adequate information, a longer message
(maximum 237 characters) may be issued.
The message is displayed on the console in following format:

Format: hh.mm.ss JOB nnnnn message
where: hh.mm.ss - Time when message displayed

nnnnn - Job number assigned by the system
message - As defined in previous “Message
format” section
• Message control
Large volume of messages should be avoided. Message counter and logic should be
implemented to avoid possible system deterioration caused by large volume of
messages.

2.6. Error Handling
Ensure that all conceivable error conditions are catered.
Wherever possible, display/printing of error messages should be handled by one common

module/routine.
Use debugging statements only in test version of program. Remove these statements before
releasing the program to production.
When a recoverable error conditions is encountered in a caller program, meaningful return

code should be returned to the calling program. Error handling should be done in the calling
program.
When an unrecoverable application error condition is hit in batch processing that should not
be continued to run in a normal condition, e.g. empty file input on a master account file, this
is an indication that some investigation is required before the program can proceed. In this
case, the program should be abended (abnormal end) with an appropriate error condition
code (e.g. COND CODE 16) to alert the operators to investigate or call the programmers for
investigation. Appropriate error messages (refer to section 2.5.3) can be issued to provide
additional information to facilitate problem investigations.

2.7. Online Programming Considerations
2.7.1. General standard
The following CICS-specific standards and guidelines must be followed:
1. Keep application programs as simple as possible. Complex and sophisticated features

usually have an impact on performance and should be avoided, unless they can be
cost-justified.
2. Use command level coding only. Always use CICS Command Level coding in your
CICS program. Below example is a way to call up a READ file request:
EXEC CICS
READ FILE(‘FILEA’)
INTO(FILEA-WORK-REC)
RIDFLD(FILEA-WORK-REC-KEY)
EQUAL
END-EXEC
Figure 2.25 Example of READ file request
3. Use operating system services with extremely care. Directly issuing an operating
system service request may cause all CICS activities to stop and all transactions to
suffer response delays.
4. Avoid lengthy calculations/processing between two CICS service requests. Insert

CICS task control wait requests with lengthy processing, this enforce control to
return to CICS periodically.
5. Prevent deadlocks, which can occur if two transactions attempt to update the same
resources by ensuring both transactions update the resources in the same order. If
each transaction updates two files, ‘A’ and ‘B’ for example, update file ‘A’ before
‘B’ is the updating order. Both transactions should follow this updating order.
6. Ensure transactions which update several records in a single file always do so in a

predicable order (low key to high, or vice versa). Transient data and temporary
storage must be included among such resources.

7. Release exclusively controlled resources as soon as possible.
8. Issue only one physical SEND per screen. It is very inefficient to build a screen in
parts and send each part with a separate command.
9. Use ‘eye-catcher’ fields at the beginning and the end of the CWA and TWA, to help
identify the start and end of these areas in a partition dump.
10. Task initiated by CICS START command can execute simultaneously with started
task. In contrast, programs invoked by LINK run as a part of a single task.

2.8. Coding for Performance
2.8.1. General COBOL Program
1. Arithmetic expressions
• Computation of arithmetic expressions that are evaluated in floating point is

most efficient if operands need little or no conversion.
• Declare integer items as COMP-3 with nine or fewer digits to afford quick
conversion to floating-point data.
• Define COMP-3 with odd number of digits (For details, please refer to
Performance Tuning section of the IBM COBOL manual in Appendix A
Reference item [2])
• Use COMP in subscripts. COMP is the best format for items used as
subscripts, in GO TO … DEPENDING, or as OCCURS … DEPENDING
objects.
• Use same numeric usage in moves, compares and arithmetic calculations and
same number of decimals for “ADD” and “SUBTRACT”.
2. Use of arithmetic operation
Use ADD / SUBTRACT / MULTIPLY / DIVIDE statements and COMPUTE

statement based on number of data items/literals involved. Refer to section 2.4.5.14
for details.
3. Avoid Redundant System Calls
Try to avoid repeated system calls if such calls can be replaced by a single call. For
example:
MOVE FUNCTION CURRENT-DATE (1:2) TO WS-DATE-CC

MOVE FUNCTION CURRENT-DATE (3:2) TO WS-DATE-YY
MOVE FUNCTION CURRENT-DATE (5:2) TO WS-DATE-MM
MOVE FUNCTION CURRENT-DATE (7:2) TO WS-DATE-DD

where CURRENT-DATE is defined in format “CCYYMMDD” and WS-

DATE is defined in format “DDMMCCYY”.
Instead, define a working data field in the same format as CURRENT-DATE and use
a single “MOVE” statement to obtain the date value.
MOVE FUNCTION CURRENT-DATE TO WS-CURRENT-DATE
then copy the sub-fields by:
MOVE WS-CURRENT-DATE-CCYY TO WS-DATE-CCYY

MOVE WS-CURRENT-DATE-MM TO WS-DATE-MM
MOVE WS-CURRENT-DATE-DD TO WS-DATE-DD
Define a new group field WS-DATE-CCYY so as to minimize the number of

MOVE statements.
4. EVALUATE
To avoid a deep nested IF-THEN-ELSE, EVALUATE should be considered if the

construct would require more than two IF statements. EVALUATE statements
should be structured so that the most likely event occurs first. Normally no more than
two levels of WHEN should be used. Refer to section 2.4.5.11 for example.
5. I/O operation
Use single OPEN instead of separate OPEN statements in COBOL program. OPEN
is a very time-consuming operation and should be executed only once or a very few
times. Use one OPEN statement to open files that are used together.
6. Handling table efficiently
Pay close attention to table-handling operations, especially if they are a major part of
an application. Several techniques can help to improve efficiency of these operations
and can also influence the optimizer. The return for your efforts can be significant.
The following two guidelines affect your choice of how to refer to table elements:
• Use indexing rather than subscripting.
Although the compiler can eliminate duplicate indexes and subscripts,

original reference to a table element is more efficient with indexes than with
subscripts, even if subscripts are COMP field. The value of an index has the
element size which is factored into it, whereas the value of a subscript must
be multiplied by the element size when the subscript is used. The index
already contains the displacement from the start of table, and this value does
not have to be calculated at run time. However, subscripting might be easier
to understand and maintain.
• Use relative indexing.
Relative index references (that is, references in which an unsigned numeric

literal is added to or subtracted from the index name) are executed as fast as
direct index references and sometimes faster. There is no merit in keeping
alternative indexes with offset factored in.
Whether you use indexes or subscripts, the following guidelines can help you to get
better performance in terms of how you code them:
• Put constant and duplicate index/subscripts on the left.
You can reduce or eliminate run-time computations by making constant and

duplicate index/subscripts the leftmost one. If all the indexes or subscripts are
variables, try to use your tables so that the rightmost subscript varies most
often for references that occur close to each other in the program. This
practice also improves pattern of storage references as well as paging. If all
indexes or subscripts are duplicates, then entire index or subscript
computation is a common sub-expression.
• Specify element length so that it matches that of related tables.
When you index or subscript tables, it is most efficient if all the tables have
the same element length. With equal element lengths, the stride for the last
dimension of the tables will be equal. The optimizer can then reuse the
rightmost index or subscript computed for one table. If both the element
lengths and the number of occurrences in each dimension are equal, then the
strides for dimensions other than the last one are also equal, resulting in
greater commonality between their subscript computations. The optimizer can
then reuse indexes or subscripts other than the rightmost.
• Avoid errors in references by coding index and subscript checks into your
program.
If you need to validate your indexes and subscripts, it might be faster to code
your own checks in your COBOL program than to use the SSRANGE
compiler option.

You can also improve the efficiency of tables in situations covered by the following
guidelines:
• Use COMP data items for all subscripts.
When you use subscripts to address a table, use a COMP signed data item
with eight or fewer digits. In some cases, using four or fewer digits for the
data item might also improve processing time.
• Use COMP data items for variable-length table items.
For tables with variable-length items, you can improve the code for
OCCURS DEPENDING ON (ODO). To avoid unnecessary conversions
each time the variable-length items are referenced, specify COMP for
OCCURS . . . DEPENDING ON objects.
• Use fixed-length data items whenever possible.
Copying variable-length data items into a fixed-length data item before a

period of high-frequency use can reduce some of the overhead associated
with using variable-length data items.
• Organize tables according to type of search method used.
If the table is searched sequentially, put data values most likely to satisfy the
search criteria at the beginning of the table. If the table is searched using a
binary search algorithm, put the data values in the table sorted alphabetically
on the search key field.
• SEARCH table entries (Refer to section 2.4.5.9)
7. Static and dynamic call
Static calls are executed more quickly than dynamic calls.
8. STRING and UNSTRING (Refer to section 2.4.5.12)
9. Data items grouping
• the most frequently referenced data items should be placed at the beginning
of Working-Storage. This helps to minimize paging.

• data names of constant value should be grouped together

• data names whose values vary during execution should be grouped together
and should be separated from those of constant value.
10. Subroutine grouping
For efficiency, all frequently used routines should be grouped together, apart from
infrequently used routines.
11. INITIALIZE
INITIALIZE on a group item should be used with caution. It can cause a large
processor overhead. Consideration should be given to other forms of initialising the
data such as:
MOVE SPACES TO A-REC

INITIALIZE A-REC REPLACING NUMERIC DATA WITH ZEROES
If A-REC had 100 items, 50 numeric and 50 alpha then the above example would
generate 51 individual moves whereas an initialize of the whole group would
generate 100 moves.
Please note that INITIALIZE does not initialize the FILLER fields within the record.
Try to use VALUE or MOVE clause instead to INITIALIZE to setup the initial value
of data items.
12. Record manipulation
If possible, perform delta add/change record processing rather than full volume while
I/O can be minimized. In addition, when performing lookup routines for large
volume of data, try to save the lookup key and used this to compare with next record
key. I/O will be saved while the lookup key is the same since the saved working
storage lookup value can be re-used.
13. Record sorting
If possible, use Syncsort sorts rather COBOL sorts as Syncsort sorts are parameter-
driven and easy for future maintenance.

2.8.2. Online COBOL Program
Online COBOL programs share the same performance coding tips with general COBOL
programs together with batch programs. In addition, main performance characteristics to
be considered when designing an online COBOL system is listed below.
• DASD and file control
• Reduce number of I/O operations

• Tune remaining I/O operations
• Balance I/O operations load.
• TS Queues
TS Queues are used as main storage for short lived data. There is also an auxiliary
storage queues for long lived or large volume data for fast access.
More detailed discussions on tuning the use of TS can be found in the IBM CICS
Performance Guide (Appendix A Reference item [8]).
• CICS START/LINK
Task initiated by CICS START command can execute simultaneously with started
task. In contrast, programs invoked by LINK run as a part of a single task.
• Virtual and real storage utilization

CICS storage management works in units of pages that are normally identical to
operating system page size. You might usefully give some thought to choosing area
sizes so that they are properly fit onto pages.
Allocations that specify a number of storage areas should be set to fill all pages used.
Storage size allocations should be defined at a size that optimizes page usage.
Allocation of storage areas that are exactly divisible by page size will completely fill
pages.

A. References
[1] IT Handbook: Volume 2, section 11, 16, 41, 46 and 51, APHIT
[2] IBM COBOL for MVS &VM Version 1 Release 2 – Performance Tuning
[3] CDU COE Local Procedures
[4] ADVANCED COBOL, McGRAW-HILL
[5] STRUCTURED COBOL PROGRAMMING, Fifth edition, JOHN WILEY & SONS, Inc.
[6] THE NEW COBOL, An Illustrated Guide, McGRAW-HILL, 1987, by A.S. Philippakis;
Leonard J. Kazmier
[7] Optimization Techniques by Computer Associates
[8] IBM CICS Performance Guide:
http://publibfp.boulder.ibm.com/cgi-bin/bookmgr/BOOKS/dfht3a04/CCONTENTS
*** END OF HANDBOOK ***

HSBC - COBOL Estandard de Codificacion

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

HSBC - COBOL Estandard de Codificacion

Uploaded by

Copyright:

Available Formats

Developer Handbook

COBOL Coding Standard

©COPYRIGHT HSBC HOLDINGS PLC 2005. ALL RIGHTS RESERVED.

David Bagge CIBM UK

Confidential ©HSBC HOLDINGS PLC, 2004 Page ii

Confidential ©HSBC HOLDINGS PLC, 2004 Page iii

Confidential ©HSBC HOLDINGS PLC, 2004 Page iv

1.2. Objectives and Intended Audience

1.3. Document Structure

1.4. Related Documents

Confidential ©HSBC HOLDINGS PLC, 2005 Page 1

The start of a subroutine is denoted by a section or paragraph name. A subroutine is

Confidential ©HSBC HOLDINGS PLC, 2005 Page 2

2.1.2. Naming Conventions

2.1.2.1. Global Naming Conventions

Global Program Naming Methodology

For example: SSSCXXXX

1st – 3rd 4th 5th – 8th

Figure 2.1 Table of global program naming fields specification

Confidential ©HSBC HOLDINGS PLC, 2005 Page 3

Global Macros Naming

For example: SSSXXXXF

1st – 3rd 4th – 7th 8th

Figure 2.2 Table of global macro naming fields specification

Confidential ©HSBC HOLDINGS PLC, 2005 Page 4

Global Naming Methodology

Description Program Sub- Program Macros

A sub-program SSS2SXXXX2 SSS2XXXX2W

A coding macro SSS3XXXX3W

A set of file SSS5XXX5[X]W

Confidential ©HSBC HOLDINGS PLC, 2005 Page 5

Figure 2.3 Table of global naming general example

2.1.3. Program Structure

The main program:

- contains the only normal exit point of the program.

Each of the subprograms normally:

- performs one (or more) of the functions of the program,

Confidential ©HSBC HOLDINGS PLC, 2005 Page 6

Figure 2.4 Program Hierarchy Chart

Confidential ©HSBC HOLDINGS PLC, 2005 Page 7

2.1.4. Subprogram Structure

- must invoke all second-level routines through PERFORM statements,

- perform a distinct function,

- have a meaningful name,

- invokes only lower level routines,

Confidential ©HSBC HOLDINGS PLC, 2005 Page 8

A100-INIT- A200-READ- C100-FORMT-MSG- Level 3

A110-INIT- A120-INIT- Level 4

Y100-READ- Y200-WRITE- Common

Figure 2.5 Hierarchical structure of a subprogram

Confidential ©HSBC HOLDINGS PLC, 2005 Page 9

2.1.5. Subroutine Structure

Each subroutine may be written in form of a paragraph or section (containing several

Format: xxxx -a....a-RTNE - for routine

where: xxxx - is a prefix in the form of one alphabetic character followed by

a....a - meaningful abbreviations which give an indication of the

In the WORKING-STORAGE SECTION, the data structure definitions of file records

Confidential ©HSBC HOLDINGS PLC, 2005 Page 10

Note: Since a routine frequently contains several PERFORMs, writing a PERFORMed

Confidential ©HSBC HOLDINGS PLC, 2005 Page 11

A100-INIT- A200-READ- C100-FORMT-MSG- Level 3

A110-INIT- A120-INIT- Level 4

Y100-READ- Y200-WRITE- Common

Confidential ©HSBC HOLDINGS PLC, 2005 Page 12