| Frank Swarbrick 2006-07-27, 9:55 pm |
| Just a few IMHO thoughts:
- It would certainly be useful for COBOL to be able to utilize objects and
interfaces created by/for other languages/run-time environments.
- However, *relying* on another language/run-time environment to be present
just to use COBOL seems to me to not be a good thing.
Specifically, I think it's a good thing that IBM Enterprise COBOL has
interoperability with Java. But I think that requiring java.lang.Object as
the base object for OO COBOL is a very bad idea. It should be *allowed* but
not *required*. (Am I mistaken that it is required?)
It seems to me that COBOL collection classes need not be part of the COBOL
standard. It seems to me that it might be more useful for someone to write
the collection class in standard(!) COBOL and release the source code to the
community. Vendors could provide these collection classes with their
compiler, if they choose. But even if they don't one could simply compile
them from source.
Or one could, if such an interface is available, use classes available for
another language/run-time environment.
Seems to me that both options have their good and bad points, and that
neither is perfect. But to have both options available would give you a
choice on which way to go.
It also seem like it would be idea if other languages could interface
directly with COBOL objects. I'm not sure how all of this inter-language
interfacing even works right now, so I can't say much more than that.
Frank
---
Frank Swarbrick
Senior Developer/Analyst - Mainframe Applications
FirstBank Data Corporation - Lakewood, CO USA
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...[color=darkred]
>
> William M. Klein wrote:
just[color=darkred]
>
> 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.
>
|