Re: Program templates as Object Classes

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

Date: Wed, 15 Dec 2004 09:58:47 -0800

Some more thoughts, interspersed:

"Pete Dashwood" <dashwood@enternet.co.nz> wrote in message
news:31cis8F38doeoU1@individual.net...

> Adding OO to it was a fantastic achievement (a far from pointless adition
> (unlike intrinsic XML and Collections)) and it still leaves me gasping at
> the people who did it, but look at the reaction: Nothing. The user base
> simply didn't DESERVE to have what was produced. Their resistance to
change
> and entrenched conservatism shot it down before it could ever fly.

There are users of OO COBOL; they are just far fewer than either the vendors
or the committee (or the proponents) expected. Most seem to have
implemented the feature content as it existed in Committee Draft 1.4, or
even before; some aspects of OO COBOL have grown and evolved since then.

> Why spend
> time adding collections as part of the standard, when all they have to do
is
> go OO, and they can have all the collections they could ever want, of
> whatever type they want?

Yes, a user can write his own library for collections of objects, and most
likely that library would be incompatible with the analogous library at the
machine next door, whether from the same vendor or not. The COBOL standards
committees *continue* to encourage vendors and implementors to provide a
*single, portable* way of doing things precisely so that that way of doing
things is independent of the platform on which, or the operating environment
in which, the program is running.

> Same with XML. The external free facilities to handle XML are more than
> adequate (if you use OO). In fact they are totally rich, and they are
free,
> for ANY language that implements a COM/CORBA interface, including OO
COBOL.

The New Zealand representatives (in particular) at the June 2003 WG4 meeting
disagreed with you that XML should be supported *first* by the OO features
in COBOL. They also disagreed with the contention that dynamic-capacity
tables and any-length elementary items should be supported *first* by the OO
features in COBOL, or, in fact, that *any* new feature of COBOL other than
those strictly associated with Object Orientation should be supported
*first* by the OO features of COBOL.

Out of curiosity, have you examined the Native XML proposal to get a sense
of what, exactly, it is (and, more importantly, is not) trying to
accomplish?

> I can't see the point in using valuable resources to provide people with
> something that is already provided, if they were prepared to invest in
some
> training and re-thinking their attitude.

Which current mechanism should J4 endorse, and why?

> How much time, effort, and money is
> being spent by J4 to provide these facilities through a standard that will
> be far too late, for a language that will be virtually dead by the time
this
> standard is ready?

How many times are you going to complain to CLC about this instead of
contacting your National Standards Body and its representatives on WG4 to
clarify your positions?

> If that time and effort was spent in getting the 2000 standard fully
> implemented NOW, (maybe even a joint development project between
> J4/ANSI/ISO/whatever and a vendor)

Hmm. Six members of J4, all of whom have other duties, four of whom are
sponsored by large companies and two of whom are self-funded consultants.
J4 is directly answerable to WG4, and WG4 does not seem to be of the opinion
that it's J4's job to get in bed with *any* vendor.

There's another piece of significance. What exactly does "getting the 2000
standard fully implemented NOW" mean, since the validation suite for
standard COBOL hasn't been updated to include any of the new-for-2002
features? How do *you* tell whether a given vendor's OO implementation is
100% up to snuff or not, besides taking the vendor's word for it? There
is no independent mechanism today whereby a compiler vendor can verify
whether his compiler complies with the standard or not.

If J4 or WG4 were to get involved in a "joint development project", I think
it'd be far more useful for that involvement to be in the development of a
standard validation suite. Such has been discussed on several occasions,
and one of the ideas that's been discussed at some length was the idea of
providing a repository for validation tests to be supplied by anyone who is
willing to provide them (I have a feeling you'd like that idea!). There are
a number of serious problems with this; for example, for such an
"open-source" validation suite to be effective, criteria for the content of
individual tests would need to be clearly specified and rigorously enforced,
and that in itself requires a significant resource investment to which the
members of J4 are not prepared to commit. If those resources were to come
from outside J4/WG4, there would need to be some sort of mechanism to ensure
that the tests were not biased toward any particular
vendor/platform/operating environment.

The COBOL standard has no teeth, and has not had teeth since the US
government abandoned its requirement that vendors supplying COBOL compilers
to it must validate those compilers against the current standard.
Personally, I think that was a black day for COBOL, and a black day for the
computer industry. If there were a strong, verified validation suite by
which conformance to the standard could be verified, it'd go a long way
toward the ability of a vendor to certify conformance!

As it is, though, the COBOL standard serves basically as a gentleman's
agreement as to what COBOL ought to look like, and serves to encourage
implementors that if they're going to implement a feature (whether part of a
full 2002 implementation or not) this is the direction they should carefully
consider going.

> and promoting the fact that COBOL was
> made viable for future development by the addition of these facilities,
you
> wouldn't hear a peep out of me.

I think I've been promoting my opinion that 2002 COBOL has been dramatically
improved for future application development since the 1985 standard and its
two amendments, and also my opinion that the features I have volunteered to
develop for the 2008 standard have made COBOL far more viable for future
development, to the best of my ability in the contexts available to me --
through CLC and within my company.

I believe the same is true within their chosen venues for each of the J4
members and each of the WG4 delegates.

I am not a marketing type, and never have been very good at that particular
role, and for me to jump into that role as a Unisys employee and start
telling Unisys what *they* ought to be doing that they're not already doing
would likely not bode well for my continued employment at Unisys or, for
that matter, my continued ability to contribute whatever talents I have to
the activities of J4 or WG4.

    -Chuck Stevens

Relevant Pages

  • Re: Program templates as Object Classes
    ... some aspects of OO COBOL have grown and evolved since then. ... Classes from ANY vendor on ANY platform can be "wrapped" (provided the ... 2002 standard implemented. ... I really don't care what J4 or WG4 or SG-1 ...
    (comp.lang.cobol)
  • Re: OO COBOL - What if ???
    ... I couldn't believe that people would sue over a standard - especially when a vendor can pretty much do whatever they want and label it an extension. ... marketing programs I wrote in the late 1960's with ALTERs ... of discontinuities between the 1974 COBOL and the 1985 COBOL, ...
    (comp.lang.cobol)
  • Re: GOBACK (was: Perform Thru/Go to vs. Perform - Compile Speed
    ... > I'm just using the features provided. ... They are not provided by _Cobol_, but by one vendor as an extension ...
    (comp.lang.cobol)
  • Re: Cobol books & experiences
    ... What Chuck is talking about is the "divide" in the Standard. ... For workstation COBOL products, having an OO feature - as well as C, C++, ... > Some vendors provided some OO features reflecting drafts of that standard ...
    (comp.lang.cobol)
  • 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)