As in the discussion above, many of the FD phrases in the
DATA DIVISION were designed to describe physical attributes of
the file being used. Such things as LABEL RECORDS, BLOCK CONTAINS,
RECORDING MODE and RECORD CONTAINS were descriptive of the external
file. With more sophisticated operating systems, these clauses
are no longer needed. All information of this type is now contained
either external to the program in the JCL or in the file itself,
or is redundantly specified here and also in the definition of
the data record which follows the FD. [Note -the only required
clause (LABEL RECORDS) in COBOL-74 is now optional in COBOL-85].
RULE 6 - Specify only the minimum of information in the FD,
namely LABEL RECORD when the compiler still requires it, and BLOCK
CONTAINS 0 (used to designate that the JCL/file will contain the
real block size instead of the program).
In earlier IBM computers, the distinction between byte-oriented
instruction and word-oriented ones was more clear. Word-oriented
instructions required that binary values be on even-byte boundaries
in order to execute properly. Thus the SYNCHRONIZED clause was
needed to inform the COBOL compiler that it was to generate direct
word-oriented instructions and did not need to move the data field
from a possible byte-aligned location to a one which was aligned
to a half-word, full-word, or double-word as appropriate. The
SYNCHRONIZED (or SYNC) clause was recommended to be used both
for all binary (COMP) fields as well as for each 01 level record
description to enable the compiler to generate more efficient
code. As newer machines no longer make this distinction, we no
longer need this phrase.
RULE 7 - Do not use the SYNCHRONIZED clause as it is no longer
necessary.
Often in edit programs, one needs a field to be defined both
as an alphanumeric field (PICTURE X) and as a numeric field (PICTURE
9). Then, if the contents of the field are numeric, it can be
moved to a numeric-edited field on an audit/error report, but
if is not numeric it can be moved to an alphanumeric field. Since
this is redefinition of a single field, the usual coding construct
is:
05 NUMERIC-FIELD PIC 9(5).
05 NON-NUMERIC-FIELD REDEFINES NUMERIC-FIELD PIC X(5).
and
05 EDITED-FIELD PIC ZZ,ZZ9.
05 NON-EDITED-GROUP REDEFINES EDITED-FIELD.
10 NON-EDITED-FIELD PIC X(5).
10 FILLER PIC X.
05 NON-NUMERIC-FIELD.
10 NUMERIC-FIELD PIC 9(5).
and
05 NON-EDITED-FIELD.
10 EDITED-FIELD PIC ZZ,ZZ9.
However this construct is overly complex. The same result
can be accomplished as follows:
This latter construct takes advantage of the fact that group
fields act like alphanumeric fields both in IF statements (like
IF ... NUMERIC) and in MOVE statements.
RULE 8 - Use the group/numeric field construct rather than
a REDEFINES for multiple field definitions needed in edit programs.
When computers were smaller and slower than they are now,
there was a great deal of attention paid to the impact of the
various USAGE clauses and when they should be used. COMP was
suggested for indexes or subscripts, COMP-3 for all internal fields
and files, and DISPLAY for human enterable/readable fields. Programmers
not only had to take additional time in deciding which USAGE to
use, but had to deal with the problems of debugging programs when
using packed or binary data.
However, computers have gotten faster and a programmers time
has gotten more valuable. If a program only runs once a month
and only has to process a few thousand records each time, then
the additional time or cost spent running the program will be
more than wasted if the programmer has to spend more than a minute
or so either deciding which USAGE to use or to interpret the binary
value in a dump or printout of a file. Also, the problem of zeroing
out a series of COMP-3 fields in a program are avoided with COMP
or DISPLAY (by moving LOW-VALUES or ZEROES to a group level respectively).
[This problem will go away with COBOL-85 when the INITIALIZE
verb becomes available.] Therefore we need to be less conscious
of the efficiencies involved than we used to.
RULE 9 - Unless a field is used in computations a large number
of times, or there are many numeric fields in a file, use the
USAGE mode that is most comfortable to you.
From time to time, there has been much discussion about the
use of the VALUE clause in the WORKING-STORAGE SECTION of a program.
Some have felt that it is only to be used for constants, i.e.
those fields that will never change in value, and not for accumulators,
end-of-file switches, etc. In fact, an early COBOL compiler for
Control Data computers supported a separate CONSTANT SECTION for
this very purpose. Others felt that having the compiler initialize
the field once when the program was compiled, rather than having
to do it many times each time the program was run, was more efficient.
As is the case in some of the earlier situations above, an
overriding guideline is to minimize the time a programmer has
to work on the program and to avoid errors which require later
correction, rather than machine efficiency. Mistakes in forgetting
to initialize a variable are much less likely to be made if the
programmer initializes the field when he is first thinking about
it, rather than declaring it while coding the DATA DIVISION, and
having to think about it again while coding the PROCEDURE DIVISION.
This will result in fewer lines of code as well, thereby making
both the development and maintenance of the program simpler.
[Note - in COBOL-85 a single line of code "INITIALIZE WS-GLOBAL-FIELDS"
can do all of this. This is recommended when using COBOL-85].
RULE 10 - Initialize global fields, such as program counters,
totals, and end-of-file switches with a VALUE clause, to avoid
forgetting the initializing MOVE statement later.