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).
As with some of the other coding constructs covered previously,
many textbook authors cover the FD statement and its various clauses
primarily syntactically without much attention paid to the real
need for the various clauses. This may be because it is usually
covered early in the book and often in conjunction with file and
record concepts. In this context, showing how the RECORD CONTAINS
and BLOCK CONTAINS clauses relate to the physical makeup of files
is useful. However, the clauses are usually only covered in that
context and then assumed during the rest of the text. No mention
is usually made of what will work practically and which clauses
are not really necessary.
Often the reasons for some of the clauses is mentioned, especially
the RECORD CONTAINS clause, but when the definition of the record
is reduced to a single line with a global definition and the actual
record layout is coded in the WORKING-STORAGE SECTION for use
with a READ INTO (see discussion of rule 18 in the following chapter),
e.g. 01 CUST-RECORD PIC X(100)., the fact that the RECORD CONTAINS
clause has lost its usefulness is never mentioned.
"The RECORD CONTAINS clause is optional, but including it
in the FD entry of all input files will help the programmer get
the size of the input record correct. Incorrect input record
size is one of the most common errors made by beginning programmers."1
"The use of this optional clause will assure that all items
of the record have been properly defined in the record description
entry, and will also provide the reader of the program with the
record size without the necessity of counting the characters in
the PICTURE clause of the record description entry."2
"STANDARD. Use the optional RECORD CONTAINS clause."3
"Though the clause is optional, it is helpful in debugging
situations, and the author recommends its use."4
Even the DATA RECORD clause is often recommended to be coded
"for documentation purposes"5 even
though the actual name of the record is usually found on the very
next line of the program. However, one author noted, "Even
the documentation it provides is of questionable value because
the record-names immediately follow the FD entry anyway."6
Only two texts which were written within the past year made
any mention that the LABEL RECORDS clause is no longer required
and is scheduled to be dropped from future releases of COBOL.7,8
Since this feature is new in COBOL-85, one would hope that others
will now mention it.
Finally, only one author made any mention of the availability
of the BLOCK CONTAINS 0 RECORDS options that is generally used
in IBM COBOL,9 even though this is the usual
coding construct in that environment and many programmers may
encounter it there.
RULE 7 - Do not use the SYNCHRONIZED clause as it is no longer
necessary.
The various textbook authors seem to disagree completely on
this subject. One states, "With IBM COBOL, every half-word
must begin on a half-word boundary ... all this is necessary because
of hardware requirements. Almost all modern computers are particular
about the alignment of data."10 Another
states, "Most computer require that the SYNCHRONIZED clause
be added to all definitions of COMPUTATIONAL clauses."11
But another states, "Although it is a common technique to
use the SYNCHRONIZED clause, especially for binary items, it is
no longer needed in newer systems."12
and even notes the reason why it is no longer needed on IBM-370
and later computers.
One author does not even seem to have an accurate idea of
what the clause does. He first states, "the reader is advised
to check his reference manual for the technical details."
and then notes "this clause should be used only with COMP,
COMP-1, COMP-2, and COMP-3 entries."13
Since COMP-3 fields only need to be byte-aligned, the author
is obviously not aware that the SYNCHRONIZED clause is inappropriate
here.
Finally, one author suggests, "It is permissible to use
COMPUTATIONAL and SYNCHRONIZED on fields that do interact with
input and/or output, but improved efficiency is then no longer
always likely. When [they are] used on wholly internal fields,
they can never do harm - and they may do some good. But when
they are used on fields that interact with input and/or output,
they can result, in certain cases, in loss of efficiency. They
only way to be certain is to run the program with and without
the COMPUTATIONAL and SYNCHRONIZED designations and see which
version takes less computer time."14
It is obvious from the above two quotations, that if this
option is frequently misunderstood by the textbook authors, then
the students who use these texts will also have trouble understanding
the concept and whether they are supposed to use the SYNCHRONIZED
option.
RULE 8 - Use the group/numeric field construct rather than
a REDEFINES for multiple field definitions needed in edit programs.
As useful as this construct is, it is mentioned very infrequently
in the textbooks. All textbooks treat the redefines clause and
show a few examples of its use, but only one instance could be
found of an author recognizing that the group/numeric field construct
was even a possibility. However, this author was quite explicit
in mentioning it.
"STANDARD. Redefinitions of numeric data to alphanumeric
should be defined without using the REDEFINES clause of COBOL.
This technique is shown as follows: ... In this example, [the
group item] is treated by the compiler as an alphanumeric data
item, as if it had been defined explicitly with PIC X(04)."15
It appears that most authors are more concerned with presenting
the syntax of each COBOL verb, clause, etc., and not with presenting
useful coding constructs that will be helpful to the programmer
in his or her career.
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.
Many textbooks do not treat USAGE except as perhaps a side
comment when discussing the PICTURE clause. Those who do give
definitions for when to use each one are similar to the following:
"COMP is recommended for items used as subscripts or for items used in extensive arithmetic. ... COMP-3 is the suggested numeric usage for all other numeric data fields.
... Alphanumeric is preferred for all other data items unless
numeric display is absolutely necessary."16
Others preferred not to discuss the topic and deferred to
others. "The reader should consult an IBM reference manual
to determine the optimal conditions under which COMP-3 can be
used."17
Finally, one author inserted this "Note on Programming
Style":
"The use of noncharacter data representation within a program
seems to follow a similar line to many of the other special usage
items described. Almost every shop would like to use the most
efficient form of data representation available for every data
item. The question again arises - 'What will the negative impact
be if we employ this type of code?' Unfortunately, many companies
have been forced to use DISPLAY representation exclusively because
of the lack of sophistication of many of their entry-level programmers.
This lack of familiarity with noncharacter representations, coupled
with the slight advantage in program debugging (you can see the
numeric representations when displayed), have caused many companies
to stay away from noncharacter data. Thus, 'human efficiency'
seems to be winning out over 'program efficiency' or 'space efficiency.'"17
But this is exactly the point - that the increasing cost of
programming coupled with the decreasing cost of computer hardware
ought to make us more concerned with what the above author calls
"human efficiency."
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.
The only textbook authors who discuss the alternatives of
using a VALUE clause verses an initializing MOVE statement disagree
with this rule. Their reasoning is as follows:
"Initialize constant fields with VALUE clauses in the DATA
DIVISION, and initialize variable fields with PROCEDURE DIVISION
statements. This aids program documentation and helps to make
programs reentrant. A batch program need not be reentrant to
execute correctly; however, it is helpful if it is."18
"As you work with more advanced programs, you will note that
they usually contain a number of data items that must be initialized
when a program starts up. Typical of these are accumulators and
counters that must be set to zero and flags or switches that must
be set to some initial state. Rather than use the VALUE clause
in the data item descriptions, programmers will often prefer to
issue instructions in a start-up or initialize-variables paragraph
to set all initial values. This approach increases the self-documentation
of the PROCEDURE DIVISION, since it contains all the instructions
that determine the values of these data items - the instructions
that initialize the data item as well as the instructions that
change the values."19
Other authors, although they do not specifically discuss this
topic, will often include a paragraph in their sample programs
that is usually titled "INITIALIZE-VARIABLE-FIELDS".
1 - Gary Popkin. Comprehensive Structured COBOL. 14.
2 - Carl Feingold. Fundamentals of Structured COBOL Programming. 78.
3 - Barry Nirmal. Programming Standards and Guidelines, COBOL Edition. 104.
4 - Gerard A. Paquette. Structured COBOL. 108.
5 - Gary Shelly, et al. Structured COBOL, Pseudocode Edition. 3.16.
6 - Tyler Welburn. Structured COBOL: Fundamentals and Style. 72.
7 - Gerard A. Paquette. 108.
8 - J. Wayne Spence. COBOL for the 80's. 54.
9 - Computer Partners, Inc. Handbook of COBOL Techniques. 13.
10- Timothy R. Lister and Edward Yourdon. Learning to Program in Structured COBOL, Part 2. 86.
11- Carl Feingold. 84.
12- Pacifico Lim. A Guide to Structured COBOL with Efficiency Techniques and Special Algorithms. 18.
13- Michel Boillet and Mona Boillet. Understanding Structured COBOL. 521-522.
14- Gary Popkin. 151.
15- Barry Nirmal. 110-111.
16- Computer Partners, Inc. 14.
17- J. Wayne Spence. 760.
18- Barry Nirmal. 111.
19- Gerard Paquette. 128