Re: A very *PERSONAL* view of ISO 2002 COBOL for the IBM (mainframe) environment

From: Chuck Stevens (charles.stevens_at_unisys.com)
Date: 02/25/05 

Date: Fri, 25 Feb 2005 10:51:17 -0800

I very much enjoyed reading Bill Klein's take on the '02 standard.

I think some of his perspectives as stated in his paper might bear
broadening even in the strictly-IBM environment that is his target audience,
and bear consideration in the broader context of platform-independent
standard COBOL. I also disagree with his characterizations in a few cases.

I corresponded with him privately on this, and this response reflects my
take on his paper as well as our subsequent correspondence.

Page numbers herein are according to a printed copy of his paper.

1) Page 19, "BAD: A-/B-margin removal": There's absolutely *nothing* to
prevent the user from conforming to the time-honored margins. I believe
it's a matter of style; the A/B margin distinction serves little or no
*practical* purpose beyond preserving tradition.

In private correspondence, Bill noted that in current IBM mainframe COBOL

        Move ABC to XYZ
    ABC.
         If A = ...

where ABC is in the A-margin (and there is no period after XYZ), a W-level
error message is issued and the compiler assumes a period is presaent, as
"ABC" must* be a procedure label.

I think I disagree fundamentally with that interpretation from a historical
perspective. ANSI X3.23-1974 states on page I-99 in the fourth paragraph of
5.7.1.2, Procedures: "A paragraph consists of a paragraph-name followed by
a period and a space and by zero, one, or more successive sentences", and in
the fifth paragraph "A sentence consists of one or more statements and is
terminated by a period followed by a space." The wording is similar in
ANSI X3.23-1985 on Page IV-35 in 6.4.1.2, Procedures, and the intent is
identical in my ancient copy of an IBM reference manual for DOS/VS COBOL
(68). "ABC" isn't a paragraph-name in the above example because it's not
*preceded* immediately by a separator period.

Thus, my opinion is that the overriding error in the above example isn't
that the period is missing after "XYZ", it's that the end of the MOVE
statement is in Margin A.

2) Page 19, "BAD: 250-character (not byte) lines": Actually, it's 256,
and it's *only* in free-form reference format, which is not the default. In
fixed-form reference format, which *is* the default, the length is whatever
fixed length the implementor defines it to be (which from all indications
has been the way it's been for a very, very long time!). There are lots of
programming tools coming out these days that work with and/or expect
something other than the classic 80-column source image, and while
green-screen editing on 80-column lines might be The Way To Go These Days in
mainframe COBOL program editing, the next generation of programmers is used
to stuff like animated tracing and debugging in real time, and the tools
that support that aren't quite so limited. Those who choose to make use of
free-form reference format are able to make use of it, but the standard
doesn't put a gun to the end-user's head to force him to do so.

3) Page 19, "BAD: potential problems with loss of columns 73-80
information": This is not new; "Margin R" has been whatever the implementor
decides it's going to be since *no later than* ANSI X3.23-1974. I would say
that an implementor that effectively changed the location of "Margin R" in
fixed-form reference format for their implementation of ISO/IEC 1989:2002
from what it was in their implementation of ANSI X3.23-1985 would have shot
himself and his users in the foot, just as he would had he done so between
ANSI X3.23-1974 and -85, or even X3.23-1968 and ANSI X3.23-1974.

True enough, this information is indeed lost if the user converts existing
programs from fixed-form reference format to free-form reference format, but
nothing in the standard forces the user to do so. The impetus for such a
change is much more likely to come from the site's adoption of a different
(and arguably more modern!) programmer's editing tool that, should the
preservation of the information historically contained beyond Margin R prove
a vital requirement for existing user shops, would provide a way of
recording that information in some other way in the source.

3) Page 20: "Performance issues: Standard arithmetic". I understand well
Bill's point here about "more accurate than" prior results may pale in
importance to existing users beside the problem that they may be "different
from" prior results. I agree with the basic principle of having a
platform-independent way of doing arithmetic, and would like to encourage
that. I am not convinced, however, that SIDI's as defined in 2002 COBOL are
the best way to go here. I am very excited about the 128-bit decimal
formats in the draft for IEEE 754, which I believe is slated to make it into
a new version of IEC 60559:1989 Before Too Long, and I have heard some
rumblings that at least one implementor is planning to provide
high-performance support for this format.

Current plans are for direct support, both for USAGE and as a standard
intermediate data item, for the Decimal128 format to be included in the next
COBOL standard alongside "standard arithmetic" as it is now specified, and
even for implementations of 2002 COBOL I'd encourage implementors to
consider including support for the explicit USAGEs and for the ability to do
arithmetic directly in Decimal128 as a "flavor" of Native Arithmetic.

Bottom line: I think a way of specifying "platform-independent" arithmetic
for those that want it is a good idea that overrides performance questions.
I think "platform-independent, language-independent arithmetic as specified
in an international arithmetic standard" is an even better idea.

4) Page 21, "Table sort": Three comments:

a) Although I grant that the IBM implementation -- and indeed most
implementations -- of SEARCH ALL provides a "binary search", the standard
doesn't require this, and indeed, not all implementations do provide it; I
am aware of at least one case in which the user base demanded the same
results from SEARCH ALL as for SEARCH even if the table wasn't in order (in
defiance of the requirements for the statement), and that pretty much
requires a serial search. Do I think the user base was shortsighted for
making this demand? Unquestionably. Do I think the implementor violated
the standard by using a serial search for SEARCH ALL? Nope.

b) In the sentence before your example, I don't see how sorting a table
before SEARCH improves its performance. I agree that sorting the table and
*then* using a SEARCH ALL instead of a SEARCH would arguably improve
performance for any table of nontrivial size.

c) Your mention of being able to produce what amounts to a "table sort"
using input and output procedures is true enough; it's not exactly new or
innovative, as the programmer's been able to do that pretty much since the
SORT verb was introduced.

5) Page 23, "BAD: IF NUMERIC on BINARY items (against PICTURE clause)"
Bill pointed out in private correspondence that all the bits in a BINARY
item are meaningful in the IBM environment. If that's the case, then IF
NUMERIC against a BINARY ITEM isn't *bad*, it's just *not particularly
meaningful*. Personally, I think having an IF NUMERIC test check the value
against its associated PICTURE, if there is one, is a Good Thing. And
things are coming down the pike ("USAGE FLOAT-DECIMAL-34", which is IEEE
754r Decimal128, is being incorporated into the Working Draft for the 2009
COBOL standard ) where being able to detect the "NaN" (Not-a-Number)
condition would be Really Useful ... In any event, nobody's holding a gun to
the programmer's head forcing him to do IF NUMERIC tests on USAGE BINARY
items, whether they're meaningful in a particular context or not.

6) Page 23 (add-on report writer): This isn't new; it's just explicitly
brought to the attention of implementors that the standard doesn't prohibit
it. Bill pointed out that IBM sold an "outside product" to provide the
Report Writer module for their '85-compliant offering, and many users have
done so for decades for SORT/MERGE. The standard basically now says "it's
OK to do that, even for required features."

7) Page 24, "BAD, BUT: ALLOCATE and FREE ..." There are IBM-unique
implementor extensions now for '85 COBOL that do this, and there will almost
certainly be compatible IBM-unique implementor extensions in future IBM
compilers, regardless of what the COBOL standard says is the *preferred* way
of doing it. They were flagged as extensions then, and I daresay they'll be
flagged as extensions in future compilers. That the standard didn't treat
"the IBM way" as "the way everybody ought to do it" or "the only
internationally-approved platform-independent way permitted" ought not be
characterized as "BAD", with or without the "BUT"!

I agree, by the way, about thedangers of having user programs allocate
memory.

8) Page 28, "Constants": In 2002 COBOL, CONSTANTs may appear *anywhere* a
literal may appear, including in PICTURE character-strings, in OCCURS
clauses, in level-numbers, etc., etc. In my personal opinion, *this was a
bad idea*.

"Structured constants" are *records*. They may appear only where a sending
data item that is a record may appear. There are cases in which a
"constant" may appear in the same context, but there are a whole bunch of
cases in which a "constant" may appear in a given context and a "structured
constant" will cause a syntax error in that same context.

What *has* been approved is for a RECORD to be declared unmodifiable at run
time.

This is a HUGE difference, and it is a distinction that J4 spent a lot of
time and effort carefully drawing. As similar as the declaration of a
"constant data item" and a "structured constant" might look, they are
entirely different items.

Again, I very much enjoyed Bill's paper, and on the main I agree with much
of it.

    -Chuck Stevens

Relevant Pages

  • Re: Method to force keeping of source
    ... It appears to me that your wish is that the COBOL standard should prevent ... environment for the compiler or in the execution environment. ... > implementor defined is one of the problems as I look at the situation as ...
    (comp.lang.cobol)
  • Re: Computer Statement Usage
    ... >> So far as I know, nothing in the standards prevents the implementor from ... But there's nothing in the standard to ensure they do use the most precise ... That is a fair and reasonable statement. ... care what COBOL COMPUTEs do with intermediate results, ...
    (comp.lang.cobol)
  • Re: SEARCH ALL
    ... is limited in its subjects to keys referenced in the KEY ... It MAY well be possible for the implementor to ... That both the documentation and the standard at the time ... I duly reported back to the salesman that it was impossible to ...
    (comp.lang.cobol)
  • Re: Method to force keeping of source
    ... but the data file is? ... the functionality of, LABEL RECORDS ARE STANDARD. ... the implementor, and the way fields of those various USAGEs are distributed ... be meaningful except in the narrow context of the machine on which the file ...
    (comp.lang.cobol)
  • Re: sprintf
    ... There would be no standard if if demons flew from my nose. ... Undefined behavior gives the implementor license to not catch ...
    (comp.lang.c)