Re: Program templates as Object Classes
From: Pete Dashwood (dashwood_at_enternet.co.nz)
Date: 12/16/04
- Next message: James J. Gavan: "Re: utility to read cobol data files?"
- Previous message: Tom Morrison: "Re: utility to read cobol data files?"
- In reply to: Chuck Stevens: "Re: Program templates as Object Classes"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Thu, 16 Dec 2004 12:13:25 +1300
"Chuck Stevens" <charles.stevens@unisys.com> wrote in message
news:cppu0n$o1c$1@si05.rsvl.unisys.com...
> 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.
Not if they move on to components using COM or CORBA. OO is just the start.
It is component development where the future lies. ( See
http://66.152.52.10/Archives/V3/V30201.asp and
http://www.aboutlegacycoding.com/default.htm?AURL=%2Farchives%2Fv5%2FV50101%2Easp)
Classes from ANY vendor on ANY platform can be "wrapped" (provided the
platform vendor supports it, of course...) with the requisite interfaces.
The components can then be invoked remotely from ANY system.
Classes running on a Univac mainframe could be utilised by a PC running
Linux or Windows, and vice versa. The network is the network. But this kind
of thinking seems to be foreign to mainframe people. And it is certainly
foreign to the people on J4. If it wasn't, they wouldn't be implementing XML
and Class libraries as COBOL intrinsics, when there are other higher
priorities. (I agree that Language elements of COBOL should definitely be a
higher priority than these two things.)
>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.
>
That is precisely what components are all about.
> > 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,
I never suggested that.
> 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.
I understand why they would say that.
I have known both the Knutsfords for over 40 years. They are very nice
people. Ken was involved in the early days with NZCS and Jean was teaching
COBOL. I had a conversation with Jean when I was in England a couple of
years back (she phoned me) and she was on J4. She understood my views on the
whole J4 fiasco and why I was embittered about it (obviously she didn't
agree, but she did listen.) As far as OO goes and the specific points you
are addressing I wouldn't expect either of them to have expertise in this
area. They make a business running traditional COBOL code and have found a
niche market which is working very well for them. They are contributing to
COBOL in the best way they see fit because their livelihood has depended on
it and they are decent people who want to contribute. That doesn't mean they
are experts in the areas we are discussing. I don't believe they
specifically disagreed with me, personally, as you state; I believe their
take on it would be as you describe above. They hadn't heard a case in
support of what I have proposed here and they are unlikely to. (Well
certainly not from me anyway...)
> 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?
>
Yes, I have read Don's paper. It is very good. But I still think it is not
necessary.
> > 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?
I believe they should focus on getting the COBOL language elements of the
2002 standard implemented. That is the third time I've said it. I know J4
are not supposed to be attached to any particular vendor, but you claim
there is vendor support on J4 so how hard can it be to have an informal chat
with some of these "company representatives" and impress on them the
importance of this?
Why? Because there is precious little credibility left in COBOL at the
moment and discussions here that keep referencing a non-implemented standard
are pathetic and frustrating. Not to mention pointless. Jam tomorrow is NOT
a solution. OK, it isn't J4's responsibility. But they are in a position to
be able to influence it. None of the people here are...
>
> > 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?
>
As many times as I feel I want to, and I am NOT complaining! I don't care
enough about this to complain. I really don't care what J4 or WG4 or SG-1
or any other US based, faceless, alphabet bloody soup body does or doesn't
do. My comments are posted HERE because it is what I believe. This is a
forum where OPINIONS can be expressed. If I thought for one minute there was
any point in approaching J4, or making representations to my local standards
body, I would've done so. It is the fact that the process is ponderous
(like wading through bloody treacle) and in the end is seen to be a
pointless waste of time, that encourages me NOT to participate. I notice
Jimmy's experience has exactly matched my own. This is an aloof, ivory tower
committee with their heads so far up their arses they can't listen to people
who DO care (like Jimmy Gavan), let alone people who DON'T care, like me.
Don't start me...
> > 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.
>
That is fair comment.
> 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?
If they say it is compliant I might be encouraged to try it and find out...
> There
> is no independent mechanism today whereby a compiler vendor can verify
> whether his compiler complies with the standard or not.
>
Maybe because the standards body has lost all credibility and few users care
about it.
My comments here were intended to try and point out some actions that might
actually regain some credibility for J4, and instead I am accused of
complaining and not going through the proper channels. I should have known
better than to try and be helpful.
> 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.
>
Whatever...
> 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.
Wonder why they did that...?
> 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!
>
Always assuming anyone cared enough to want such verification. If the
vendor's product does the job why would anyone care if it conformed or not?
Why do you suppose people use vendor supplied non-standard extensions? It's
because they do the job.
It is really sad to see discussions here about features of COBOL that "are
in the 2002 standard", as if that means something...
Bollocks! It is unreal until it can be used.
> 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.
>
Good. My objections are not personal.
> 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.
>
I never suggested that, and it is a gross distortion of what I DID suggest.
Enough from me. I wish you well. I won't be posting on this any further.
Pete.
- Next message: James J. Gavan: "Re: utility to read cobol data files?"
- Previous message: Tom Morrison: "Re: utility to read cobol data files?"
- In reply to: Chuck Stevens: "Re: Program templates as Object Classes"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
