Re: Program templates as Object Classes

From: Chuck Stevens (charles.stevens_at_unisys.com)
Date: 12/14/04 

Date: Tue, 14 Dec 2004 09:15:33 -0800

"Pete Dashwood" <dashwood@enternet.co.nz> wrote in message
news:327bp2F3jnnn7U1@individual.net...
> Thanks for that, Chuck.
>
> Given that resources are limited and time is pressing, I have to say again
I
> cannot see justification for EITHER Collection Classes OR Embedded XML.
The
> people who are likely to use these facilities are already using them
through
> third parties and public domain software. Others who might want to use
them
> would need to go OO (OK, not for XML, perhaps) and once they do that, they
> don't need the intrinsic capability. There is therefore no pressing need
for
> them.

The argument for standardization is that it's done the *same* way in all
implementations. That's the point. I went through this when I was working
on the ISO Date/Time formats proposal. The COMBINED-DATETIME function was
provided *precisely* so that a *single standard* numeric format including
both date and time values (calendar from 1600AD, times to the nanosecond)
would be *specified*. The arithmetic in the function is trivial; the point
is that the formula is specified, not left up to the user. And there was
indeed user demand for just such a function, and just such a format. That
there might be any number of *other* such timestamp formats that could have
been, or could be, developed, here's one that everyone is *encouraged* to
use for portability.

> Why not focus on getting COBOL 2002 implemented by SOMEBODY? The action of
> doing this would regain a bit of credibility.

I've been doing what I can in my area of responsibility. But I don't
personally see a lot of customer demand for some of the mandatory features,
like OO.

A side comment: I know only enough about OO to be a bit dangerous. My
personal focus is on "core COBOL" and extending what's already there. Of
the thirteen features WG4 put on its "must-have" list, I personally accepted
responsibility for six. Four of these were trivial, two were not. All of
them, *I believe*, fundamentally enhance "traditional COBOL". They were, in
ascending order of complexity (together with the most recent relevant J4
document numbers on the subject):
        Increase minima for record locks (04-0057)
        Increase maximum size of alphanumeric literals (04-0055)
        Eliminate cryptic reference to "hardware" in ACCEPT rules (03-0263,
amended by 04-0191)
        Allow <> as synonym for NOT EQUAL (03-0224)
        Structured Constants (04-0056, amended by 04-0192)
        Support for Dates in ISO 8601:2000 Formats (04-0120, amended by
04-0193 and 04-0196)

In addition, at the WG4 meeting in October, with the support of J4, I
presented a discussion of the 128-bit floating-point formats (and the
*decimal* floating-point formats of various sizes) being proposed by IEEE in
their rewrite of IEEE 754. WG4 added this to their "wish list" for the 2008
standard, and I'm hard at work preparing a proposal for the standard to
include it (among all my other duties). The first draft of this was
J4/04-0219; a second draft, reflecting the discussion at J4 Meeting #249
last week, is in preparation; I'd suggest waiting for that one (J4/04-0251).
It should be available before the first of the year. My personal opinion
that providing platform-independent, language-independent formats for
arithmetic operands coupled with the specific arithmetic and rounding rules
associated with those formats goes a LONG way toward improving the
portability of COBOL, and I would contend that that's a *necessary* change
if COBOL is to survive as a language.

One of the reasons I bring this list up is that none of these topics have
much at all (if anything) to do with either OO or XML. I also bring it up
as evidence that my personal interests lie in the improvement of what's
already available in COBOL, and the elimination of those aspects of COBOL
that are perceived to be deficiencies or limitations.

You've indicated that you see no requirement for standardized OO or XML
handling in COBOL; well, it appears that corporate participants in J4 like
Micro Focus, Fujitsu and IBM, together with some private consultants, have
encountered enough customer demand for these features to lobby for their
standardization. Neither OO nor XML is within my personal realm of
expertise, so I don't put myself in the front line of those discussions. I
shouldn't be called to task for focusing unduly on OO and on XML; I didn't
write those proposals, and my personal priorities have been elsewhere both
within the context of J4 and at Unisys.

> > What I see as a problem (and the problem I think J4 had) with many of
the
> > earlier proposals relating to a class library for COBOL is that the
> > proposals were too broad in scope, and that included some of the things
> > Jimmy suggested in his papers. What J4 was directed to produce was
> > specifically and precisely limited to those classes *that directly
support
> > collections*.

> And nobody asked "Why?". Is nobody on this committee using OO? Are they
not
> aware there are free components available to implement both of these
> functions?

There are free components available that run on any platform or in any
environment with exactly the same functionality and using exactly the same
interface? That's the problem, Pete. There may be five sets, or fifty,
each relating to a specific environment and need. Which one is the *right*
one from COBOL's standpoint, and why? Yes, the committee is aware that
there are such components, just as they are aware that anyone could write a
user-defined function providing some sort of date/time timestamp in just
about any form the user wanted. The committee felt that developing a single
recommended approach to this problem was more consistent with language and
application portability than saying "do what ya wanna do".

> If they are aware, then why are they entertaining it?

Asked and answered.

> I understand they are trying to do their best here. It is suffering from
> lack of guidance, leadership, and answerability, as I mentioned before.
> Someone needs to call a few shots and demand some justifications.

I believe that's been done. J4 is responsible for the details of feature
implementation. WG4 is responsible for the feature *content*. J4 advises
WG4 as to what it believes is appropriate; WG4 either agrees or disagrees,
and it's WG4 that's got the final say. WG4 is made up of representatives of
the National Standards bodies of the member countries. The UK (BSI), Japan
(JISC), Germany (DIN), and the Netherlands (NEN) almost always participate,
as does New Zealand (SNZ), though the Kiwi contingent was unable to be at
the most recent WG4 meeting in The Hague.

If, for example, DIN on behalf of Germany says "yes" and NEN on behalf of
the Netherlands says "yes", do you really think it would be effective for J4
to go back to WG4 and say "But ... but ... we can't do that! Peter
Dashwood thinks it's a bad idea!!!" ?

    -Chuck Stevens
> And, in my opinion, THAT was too much... (sorry, Jimmy, have to call it
like
> I see it...)

I understand that, Peter; the problem is that you didn't convince the
National Standards bodies of several countries who formally express
significant interest in the COBOL language that OO and XML handling in COBOL
was a bad idea.

I will comment that my recollection of the attitudes of the NZ delegation at
the previous WG4 meeting is that they were *adamant* that new features
should *first* be implemented in "core COBOL" and *only then* would OO
analog syntax be considered (which is why XML handling is in the language
rather than in a class library). They didn't seem all that interested in
OO, in fact. Have you expressed your views on Dynamic-Capacity Tables and
Any-Length Elementary Items to your national standards body or to those who
actively represent it at WG4 meetings? I would say the very existence of
these proposals for the 2008 draft owes much to the SNZ contingent; if
they're wrong-headed, you need to express that *to them*.

    -Chuck Stevens

Relevant Pages

  • Re: cobol data format!!! urgent!!!
    ... which implies 559 is not an ISO standard. ... importation into COBOL programs on grounds of portability. ... formats are virtually useless *within* the COBOL program, ... that neither went their own way nor went with IEEE. ...
    (comp.lang.cobol)
  • Floating point and insularity was Re: cobol data format!!! urgent!!!
    ... the main need from a COBOL programmer's point of view is the ability to ... I look upon the lack of IEEE floating point in the IBM ... implementing the 2002 standard and making the floating point usages IEEE ... >>formats for each platform. ...
    (comp.lang.cobol)
  • Re: cobol data format!!! urgent!!!
    ... standard, be it ISO 10967 or ISO/IEC 1989! ... Because Cobol offered no floating-point, ... "The encoding of extended formats is implementation-defined, ...
    (comp.lang.cobol)
  • Re: What could J4 (or WG4) do (was: INSPECT and TRAILING syntax
    ... my intent was "The reports of the demise of the COBOL ... If I was on this committee, ... Was there stuff in it that was obsolete before the standard ... draft but not in 2002 was on the original list from WG4). ...
    (comp.lang.cobol)
  • Re: XML and OO COBOL
    ... there's an ISO standard on a subject, that standard is presumed to be in ... WG4 that established the final rankings. ... > current COBOL Spec. ... Need a compiler for such an environment support the DELETE statement? ...
    (comp.lang.cobol)