For Programmers: Free Programming Magazines  


Home > Archive > Cobol > July 2006 > Re: Micro Focus position on the "Standardized" OO Collection Class Technica









You are viewing an archived Text-only version of the thread. To view this thread in it's original format and/or if you want to reply to this thread please [click here]

 

Author Re: Micro Focus position on the "Standardized" OO Collection Class Technica
Fredrick.Underwood.Devrie@gmail.com

2006-07-27, 9:55 pm


William M. Klein wrote:
> I thought some of you in this forum might be interested in a document just
> posted to the (public) J4 website. See:
>
> http://www.cobolstandard.info/j4/files/06-0076.doc
>
> --
> Bill Klein
> wmklein <at> ix.netcom.com


Having read this paper and others available on this web site, I find
your submission to be quite, well, I want to say STUPID but I'll just
say very short sighted.

First, the document doesn't really talk about anything other than your
threat, your desire to kill this Technical Report, which as I
understand it, Micro Focus as a company is free to ignore. Nothing is
binding in a Technical Report. There is no way for J4 to proces this
paper and there was no reason to submit it other than to cause
controversy and contention. Posting it to this group leads to
confusion, futher controversy and well, ly it shines a negative
light on you and the company you represent. It's like publically
calling a duel. How uncivilized.

Second - without the Collection Class Library standardized, there is no
portablility amongst compilers (which may well be Micro Focus' intended
goal, locking you into their solution) as to this interface with OTHER
OO languages.

Short sighted and stupid. If this really is an official Micro Focus
position, I would hope that Micro Focus wakes up and realizes that
instead of attracting customers with this stand they are driving them
away.

William M. Klein

2006-07-27, 9:55 pm

If you are a strong supporter of COBOL portability, then I assume you are aware
that there are NO implementations of either the current ANSI or ISO COBOL
Standard. Not know which vendor's or vendors' compiler you are currently
using, I am forced to ask if YOU (or your company) have asked your vendor to
provide a conforming compiler? Also, do you currently compile using "standard
conforming" flagging.

My experience (both when working for a vendor, working as a member of the user
group of another vendor, and from years watching this forum) is that actual
COBOL programmers do NOT code "conforming" COBOL source code, so that
"portability" via standardization simply doesn't exist.

***

As far as the reason for this specific paper, J4 *will* be voting on the TR next
w (which by the way as stated in another submission is actually a "Technical
Specification" rather than a "Technical Report" according to current ISO usage).
Therefore, this paper was intended to provide advanced warning of the action
that Micro Focus will be taking at the meeting. Personally, from previous
standards-group work, I find getting advanced warning useful. If you have
worked on some other committee, you may not have found this useful, but I have
never heard that on J4.

As far as this being "short-sighted," Micro Focus has found that the amount of
current COBOL-only OO applications is virtually nil. OO COBOL on Windows, Unix,
and Linux tends to exist in "mixed language" applications. Therefore, as stated
in the paper, MF will continue to work on improving support for such
inter-operability, but will NOT try and enhance COBOL-only (RESTRICTED to COBOL)
tools (for OO).

It should be noted that IBM, for example, currently only supports OO COBOL (on
z/OS) in a "Java" environment. As Java DOES include "collection classes" - the
need for COBOL-only interfaces is non-existent. In fact, trying to force COBOL
semantics on mixed COBOL/Java is counter-productive (for their customers).

***

Finally, it is my expectation that there is a pretty good chance that J4 *will*
forward the Collection Classes document to ISO for national body vote at their
meeting next w. If you think the current specification is a GOOD thing for
COBOL, then I would suggest that you make certain that your national standards
body is aware of your view. It is (partially) to alert members of this forum to
the upcoming international vote and its issues that I posted my original note.

The other reason, is that my past impression of this newsgroup is that many
(certainly NOT all) members did NOT think the current J4 specification was the
correct way to go.

--
Bill Klein
wmklein <at> ix.netcom.com
<Fredrick.Underwood.Devrie@gmail.com> wrote in message
news:1154021658.148982.275810@i42g2000cwa.googlegroups.com...
>
> William M. Klein wrote:
>
> Having read this paper and others available on this web site, I find
> your submission to be quite, well, I want to say STUPID but I'll just
> say very short sighted.
>
> First, the document doesn't really talk about anything other than your
> threat, your desire to kill this Technical Report, which as I
> understand it, Micro Focus as a company is free to ignore. Nothing is
> binding in a Technical Report. There is no way for J4 to proces this
> paper and there was no reason to submit it other than to cause
> controversy and contention. Posting it to this group leads to
> confusion, futher controversy and well, ly it shines a negative
> light on you and the company you represent. It's like publically
> calling a duel. How uncivilized.
>
> Second - without the Collection Class Library standardized, there is no
> portablility amongst compilers (which may well be Micro Focus' intended
> goal, locking you into their solution) as to this interface with OTHER
> OO languages.
>
> Short sighted and stupid. If this really is an official Micro Focus
> position, I would hope that Micro Focus wakes up and realizes that
> instead of attracting customers with this stand they are driving them
> away.
>



Sponsored Links







Also available: Server administration forum archive | Web Design forum archive | Software forum archive | Hardware reviews archive

Copyright 2008 codecomments.com