Document Number: J4/03-0052
March 2, 2003
D-15 Page 1 of 9
Subject:
Strongly Typed File Records
Author:
Thane A. Hubbell
Previous Version:
NA
References in Document:
1.
ISO/IEC 1989:2002, Programming language COBOL:
Other References:
John Piggott (Piggott @ spc-systems.com)
The defect was submitted directly to J4 by Mr. Piggott
General Discussion (From initial Defect report)
The current Standard allows any number of different strongly-typed records to be written
to a COBOL file but does not permit them to be read back unless the order of arrival can
be precisely predicted.
This document arose from correspondence between the author and
members of J4 during December 2002 and was subsequently requested
by them. This working paper has been produced before any further work
is done, because the solution adopted may not be obvious to all and
requires consensus.
The current Standard restricts the use of strongly-typed record formats in
the File Section. It states in effect that, if an FD has a strongly-typed level
1 record description following it, it can only have one record description.
This is because level 1 record descriptions following an FD implicitly
Document Number: J4/03-0052
March 2, 2003
D-15 Page 2 of 9
redefine each other and any kind of redefinition is prohibited for strongly-
typed data descriptions.
Nevertheless, the Standard allows any number of different strongly-typed
record formats to be written easily to a file using WRITE (or REWRITE)
FILE … FROM …, for example:
But whilst allowing such a file to be written in COBOL, the Standard
provides no way to read the records back from the file (see note 1) unless
it is known in advance what type of record is next, in which case READ
INTO can be used. In fact, it is extremely easy to read a record,
accidentally or deliberately, into the wrong type of data area (the "phoney
record") and thus to subvert the very purpose of strong typing.
Obviously it is untenable for a system not to be able to read its own
handwriting. This paper was written just to correct this anomaly, not to
promote any philosophy of complex vs. simple file structures.
There are two main approaches:
Possible Approach #1
Forbid multiple WRITE ... FROM statements in such a case, i.e. bar
the above scenario, as if to close an unintentional loophole.
We need to leave aside any philosophical arguments in favor of
multiple record types for now and consider only practical questions.
First, there are some points of view supporting this approach:
Document Number: J4/03-0052
March 2, 2003
D-15 Page 3 of 9
- Under the rules for WRITE FILE … FROM … the Standard says that
an implicit MOVE is made from the named record area to an implicit-
record having the same description. But since such records would not
be allowed anyway as explained above, the WRITE statements would
be illegal. But since we imagine the implicit-record exists only for the
instance and then conceptually vanishes after completion of the
WRITE, it is hard to support this argument.
- Since this is an anomaly or loophole that cannot be fully exploited, it
does no harm to tighten it up. No one will be affected since the file
cannot be read back in COBOL. The problem with this argument is
that programmers have always historically enthusiastically exploited
tricks and loopholes. They will use this and will find a way around the
read-back problem, as discussed below.
Now for the points against this approach:
- A potentially affecting change. Any modifications to this recent new
Standard will not take effect until the current Standard has been well
used, and by then many programs could be affected.
- Stating a rule would be difficult. We would need to say something
like "if the source unit contains a WRITE FILE referencing a strongly-
typed item, any other WRITE FILE statement for the same file must
reference an item of the same or equivalent type". But this does not
cover all cases: the FD could have a level 1 record of a different type,
or of no type at all. This record could be innocuous (programmers are
used to coding some sort of record after an FD).
- There's a simple code-around. Just by coding an untyped level 1
record after the FD and using WRITE record-name, apart from a
possible pitfall of record length, the programmer gets over the problem
completely. (Strongly-typed items can always be used as sending
items.)
Possible Approach #2
Explicitly allow multiple-format files containing a strongly-typed record
to be written and read, i.e. complete the circle.
There are several points of view supporting this approach:
Document Number: J4/03-0052
March 2, 2003
D-15 Page 4 of 9
- Programmers historically have always expected files to be able to
contain different record formats. Some users even have a convention
that every file must have a special header and trailer.
- We presumably want to encourage the use of strong typing, for
example to protect illicit redefinition of any of the several numeric
formats COBOL provides. These formats are already used in
traditional files. If we restrict usage to a single record format, strong
typing will be of little use in "legacy" file structures.
- Future COBOL formats may be devised that require strong typing
(maybe something similar to object references, but applying to files).
We cannot predict how restriction to a single record format might
cramp such future developments.
- The current situation presents quite a nasty "gotcha". A programmer
might well write one program to write a multiple-format file (or enhance
an existing program to do that) and then find that there's no way to
read the file back in the next program. It's not a simple matter to come
to this conclusion, as the author discovered. Of course, what will
happen is that the programmer will simply suppress the STRONG
keyword (REPLACE ==TYPEDEF STRONG== BY ==TYPEDEF==)
and the facility will lose respect.
- By providing a formal way of reading a multiple-format file, we tempt
the programmer away from that nasty problem, discussed at the start,
of reading "blind" and getting a "phoney record". (See Open Issues.)
So proceeding now with Possible Approach #2, we need to evaluate
different possible language extensions:
Suggestion #1
- Permit more than one level 1 record in the file section provided that a
SELECT WHEN is present on each record and only allow a record (or
any subordinate item) to be moved if its SELECT WHEN condition is
true. For example:
Document Number: J4/03-0052
March 2, 2003
D-15 Page 5 of 9
This idea seems more promising and it satisfies traditionalists by
relaxing the rule against implicit redefinition in the file section in
exchange for a very "reasonable" requirement of selection by
condition. However it too has problems: (1) implementations will have
to generate an implicit test for the condition every time any of the file
section records is accessed, or any of its subordinates, including
elementary data items. This is not a trivial matter: even when an
elementary item in the record is referenced, e.g. in a condition, the
implementation will need to generate a test equivalent to "IF condition-i
… ELSE (generate some standard exception)". (2) by allowing implicit
redefinition in the file section, we would need to defend not also
allowing explicit redefinition in other sections, under the same
strictures.
Suggestion #2
- As the previous suggestion, i.e. permit more than one level 1 record
in the file section provided that a SELECT WHEN is present on each
record, but only allow a MOVE statement from the level 1 record-
name. For example:
Document Number: J4/03-0052
March 2, 2003
D-15 Page 6 of 9
Here the MOVE statements would be the only permissible action. This
suggestion overcomes the foregoing possible objections from devel-
opers but it seems artificial to restrict reference to one type of state-
ment. There is a more serious problem with this suggestion. Note that
it requires the file section record to be moved into working-storage in
order to be processed. Now, assuming that the same type definition is
used for both the file and working-storage records, all the data-names
in them below level 1 must be qualified whenever they are used. But,
since the data-names in the file section cannot be referenced anyway,
they are really superfluous, so the need for qualification is just a
nuisance with nothing gained in return. See note 2.
Suggestion #3
- Require the receiving areas to have a SELECT WHEN and have a
kind of selective READ INTO which tests the SELECT WHEN
conditions. For example, something like:
where exactly one of w-rec1, w-rec2 receives the contents of the
record depending on which is the first area whose SELECT WHEN
condition will be true after the implied MOVE.
The problems with this approach are: (1) what happens if none of the
conditions are true? (WHEN OTHER is not allowed outside the file
section.) (2) how does the program "know" which area has been read
into? (All the conditions will need to be tested again.) (3) this is a big
change to the READ statement.
Document Number: J4/03-0052
March 2, 2003
D-15 Page 7 of 9
Suggestion #4
- Continue to forbid more than one level 1 record and have a kind of
multiple-choice READ INTO. For example, something like:
where each condition is formed from data items in the record (f-rec).
The conditions are tested in the order written and a true value causes
that area to receive the record.
This syntax gets round some of the conceptual problems of the
previous solution, but it is really no better than "trusting the
programmer" and simply allowing a direct MOVE into a strongly-typed
record.
Suggestion #5
- Allow a MOVE of data from a non-typed record in the file section to a
strongly-typed record elsewhere, provided that a SELECT WHEN is
present on the receiving item and the condition is true after the MOVE.
For example:
Document Number: J4/03-0052
March 2, 2003
D-15 Page 8 of 9
Here there is just one skeleton file section record which is not typed
and which "represents" all the possible record layouts, whether typed
or non-typed. One possible question is how the READ statement
behaves when there are several record layouts of different sizes but
only one level 1 record in the FD. Presumably this does not cause a
problem.
Note that this suggestion would apply only to a MOVE from the file
section, not the implied MOVE of a READ … INTO. It might be
wondered why we do not simply allow any operation from any section.
The reasons are:
- Outside the file section, strongly-typed items will not necessarily
contain identifying values.
- READ (or RETURN)… INTO is already allowed without any
restriction and we don't wish to introduce changes.
OUTLINE OF PROPOSED REVISION:
It should be apparent by now that Suggestion #5 is preferred. In
summary, the formal proposal will provide:
New syntax rule:
A MOVE to a strongly-typed item from a differently-typed or non-typed
item is permitted, provided that:
- both items are level 1
- the sending item is in the file section
- the receiving item has a SELECT WHEN clause
New general rule:
In the above scenario, the condition associated with the SELECT
WHEN clause must be set to true as a result of the execution of the
MOVE statement. Otherwise a (new) exception is raised.
There are no substantive changes.
Document Number: J4/03-0052
March 2, 2003
D-15 Page 9 of 9
To Be discussed
None
