"Standard" OO COBOL Collection Classes (was: OO COBOL - What if ???

"Standard" OO COBOL Collection Classes (was: OO COBOL - What if ???

Post by William M. » Mon, 08 Oct 2007 05:57:07



<snip>

Just in case I didn't post the "final" (for the moment) status on what happened
with OO COBOL Collection Classes, I thought I would post it now.

The "end" results are:

1) The OO Collection Classes Technical Report (TR) passed its ISO ballot.
Direction has been made to make some MINOR editorial (mostly) changes - but it
should be published relatively soon. The version that was balloted on can be
viewed online at (down-loaded from);
http://www.yqcomputer.com/

2) At its most recent WG4 meeting, direction was taken to *NOT* include this
facility in the draft Standard currently under devlopment. Instead, it is
intended to be "maintained" as a TR until (if ever) it is "widely implemented"

3) Many of those implementers who have current OO COBOL implementations
- have their own (non-Standard/TR conforming) Class libraries
and/or
- have documented acces to C++, C#, and/or Java class libraries from COBOL

4) I have not PERSONALLY heard of ny implementations "announced" (much less
availabvle) that actually conform to the ISO TR. My *perception* is that this
is viewed as "too late" and that most OO COBOL users will use those libraries
available from other OO languages.


--
Bill Klein
wmklein <at> ix.netcom.com
 
 
 

1. CCC - CODASYL COBOL COMMITTEE and ANSI (was: OO COBOL - What if ???

2. OO-COBOL for Unisys IX (was: If you were inventing CoBOL...)


This is a misunderstanding. OO-COBOL is not a preprocessor for UCOB. At
least according to the manuals, you could use OO-COBOL _instead_ of UCOB, and
providing all the extensions like Embedded SQL, DMS access, and IBM Tape
processing.

The PC produces intermediate code which is sent to the host and is
processed there by @OCOB, with an O, not by @UCOB. @OCOB produces an Omnibus
which could be directly @XQTed or @LINKed.

The transfer of this intermediate code from the NT-workstation to the
host is done automatically by the workstation program.


Probably the compiler licenced from Hitachi is to much tied into WinNT
that it can easily be ported to OS/1100.

Also, I think that a workstation based editor can be more productive --
OO-COBOL comes with a COBOL editor with syntax highlighting, and I doubt that
this can be done as effectively with @IPF. See Vol. 4 of the OO-COBOL manuals
(publication number 7851 5855-001).

Yours,
L. Willms
------------------------------ all rights reserved ------------------------

3. OO Design Kernels: Fusing OO Cells + OO Life Blood

4. Support Open & GCC-COBOL (was: New Cobol compiler written in Cobol)

5. CoBOL moved to OO

6. Thoughts on teaching OO concepts to COBOL programmers

7. OO COBOL - What if ???

8. IBM, OO COBOL and related IBM products (was: Reasonably pricedCOBOL products

9. OO and "mainframes" (was: If you were inventing CoBOL...)

10. Parallelism between computer science and experience WAS: SQL wrapper in OO cobol

11. S013-C0 while compiling OO COBOL program using a job step.

12. OT Golf WAS CoBOL moved to OO

13. IBM COBOL & REENTRANT code (was: Confessions of an "OO Foreigner"

14. XML and OO COBOL

15. OO-COBOL for Unisys IX