Re: Program templates as Object Classes

From: James J. Gavan (jjgavan_at_shaw.ca)
Date: 11/24/04 

Date: Wed, 24 Nov 2004 01:11:46 GMT

Lueko Willms wrote:

>JJG> You are no doubt well versed in other OO languages,
>
> unfortunately not
>
>
>
That's a real bummer. I was sure you made some reference to using Ada
(?). It would appear that your ideas with regard to OO are
conceptual/abstract. Unfortunately when you go for a particular language
and how it is structured then you design/code within the constraints of
that language - but the objective is common to all OO languages.

Not much point in my pursuing Exception Handling here, you are
conceptualizing in a general sense, and Pete Dashwod is no longer
interested. The only other I can think of directly is Donald using both
F/J and M/F - and we'd probably get more out of it if we communicated
privately. Although not into OO specifics as regards COBOL, there are
probably others who could have contributed with general and sensible
observations.

Here's the problem with OO COBOL - it is still very incomplete.. Back
around '93 the earliest OO Compilers were released, based on the
general format for OO COBOL syntax that J4 had determined - there have
been minor changes since, one such is REPOSITORY used to identify the
classes you will be invoking from your current program as opposed to the
Micro Focus syntax CLASS-CONTROL. There were three, IBM (Visual Age),
Hitachi and Micro Focus - some while later Fujitsu joined the fray so
their very first version included the syntax REPOSITORY.

The latter three, realized that OO was incomplete without support
classes (utilities), so each in their own way introduced varying
degrees of support utilities, string handling for objects, arrays,
collections etc. Each of the three introduced their own versions of GUI
tools. All their creations were *extensions* to COBOL, plus the COBOL
Standard does not acknowledge different operating systems - so any
GUI/Webbing features are 'alien', not universal to COBOL - and yet it is
really difficult to perceive any PC application that doesn't need, as a
minimum, some form of GUIs, plus a link to the Internet if you get into
Webbing.

It's about two years ago a former, retired M/F Manager, (not Bill Klein
;-) ), said any OO language without support classes was doomed to
failure. He was well aware of what I spell out for Fujitsu, Hitachi and
Micro Focus above - but he was referring to the fact that Standard
COBOL, (COBOL 2002) does not have the above. He *was* excluding GUIs
from his comments. He didn't spell it out but was probably also
contemplating things like Open Source routines - we are all aware of
third-party routines written for other languages and the availability
through the Internet.

Bearing in mind OO COBOL was formulated back in '93, it is only now that
J4 are seriously looking at Collections ONLY - and the initial objective
appears to have been KISS, (Keep it simple), tentatively at this time
going for three collection types Ordered, Unordered and KeyedCollection,
(the latter being a Java Map, or in Smalltalk/Net Express parlance -
Dictionary). I wont hide the fact that I was *extremely* annoyed the
above doesn't include SortedCollection - which is at least 80% of my
usage - and I've said so to J4. Remains to be seen what happens.

This whole biz is a topic first tackled by a Russell Clarke in Australia
- an ENORMOUS effort put in - and the damn thing went into a cryogenic
state until resurrected by Bill Klein, then a J4 member. Bill is not
enamoured of OO but just wanted the *best* for COBOL. Russell's paper
title "Standard Classes". First crack at the resurrected topic the title
became "Standard Collections" - jaundiced maybe but I felt we were being
handed the Fujitsu format - when I had stressed back in 2000 - we should
have 'horse-trading' between F/J, Hitachi and M/F to take the best from
all three - Pete may recall my phrase 'horse trading'. I specifically
made that same point to J4 back in 2000.. (Subsequent to the
'resurrection' event Fujitsu drops out of J4 - I can only make the
wildest guess - they have put their eggs into the dotNet basket ? Just
introduce, as necessary, their own non-Standard syntax to handle
dotNet. M/F have done exactly the same with features like TRY...,
CATCH...., END-TRY. But at this stage I believe M/F are still very
committed to non-dotNet COBOL - there's a whole slew of of us that fit
in that category).

I'm not sure about Fujitsu, but both Hitachi and M/F introduced support
utilities which changes our title from 'Standard Collections' back to
'Standard Classes'. The reason - both based their initial design on the
Smalltalk model which has in excess of 1,000 support classes. I've never
checked but some of the Smalltalk classes may possibly be no bigger than
one method - a parallel in COBOL, and still not yet introduced by any
vendor - our UDFs (User Defined Functions). Trouble with that - "Which
class has methods that I feel are appropriate ?" - requires a lot of
searching.

 (Note for Pete - having read Will Price on M/F and dotNet - I'm
inclined to think F/J dotNet would be overkill for you, as you just want
components. However, and I'm sure it is dotNet based, as you start to
type in a class name the IDE gives you a treeview of all methods
applicable to that class - nice feature. Via dotNet you get 'overload'
on the amount of detail for Exceptions - but you can select what you want).

Well aware of the M/F support class structure, and how it applies to
collections, I initially went with the abbreviated 'Standard
Collections' approach, because I got the feeling J4 wanted KISS.

OK guys recall Alain Reymond, Belgium wanting to produce some Open
Source with Postscript ?. Commendable idea, and I waved a few warning
flags about being 'neutral'. In subsequent private e-mail, Alain wrote,
"No I wont be using any GUIs but I do want to use the M/F Class
CharacterArray, and *hope* there is some F/J equivalent, say like String
class).

Frankly I think Alain is scuppered - the M/F class CharacterArray is a
SUPPORT Class.
The M/F Collection classes draw off this support class as necessary. In
addition when you look at the start of the source code for Class
CharacterArray there are a whole daffy of other M/F support classes
which are invoked, dependent upon the methods you use in CharacterArray.
Unless Alain is a wizard - to my mind - game over ! (I'm not going to
write Alain off - he may well be a wizard from le Pays Bas !).

Clicking into Alain's problem - the very probable difficulty of
producing portable, 'universal code' I've suggested to J4 they have a
think about 'Standard Classes'. In reference to something I wrote it was
Robert who commented, "Why should vendors provide you portability, allowing
you to easily switch compilers ?" Cynical if you like, but deadly accurate !

I feel no need to impress others, wrapping my thoughts and comments in
a false 'academic' style, nor do I seek out Thesaurus for a nice
alternate word - so as a developer, plugging away at this stuff on a
daily basis, I just tell it like it is - hopefully without insulting
anybody. So quoting Robert anonymously, I wrote to J4 suggesting they
had two options :-

(a) Go for just Standard COLLECTIONS - ignoring support classes, (which
are then implementer defined) - and I wrote, "no criticism of vendors -
you are not non-profit charitable organizations", or

(b) Acknowledge/Agree that we need a set of Standard CLASSES, (which
would include Collections), which are portable across different compilers.

Bearing in mind J4 is now down to 6 members, four of whom are vendor
reps, IBM. HP, M/F and Unisys - whether they go (a) or (b) above remains
to be seen. It's their decision - and unless somebody is a real
muck-raker and visionary on ISO (the WG4 Committee), I think the ball
on a decision will remain with J4. Anyway I'm reasonably certain Team
USA for ISO = WG4, consists of the 'producers', the the four J4 vendors
= ANSI = USA :-). Germany may or may not include Artur Reimann, (active
as a J4 member until an illness in 2000), and Karl Kistler, Chief
Architect for Fujitsu-Siemens, (a corporate partnership between the two,
not directly associated with the Fujitsu we are more familiar with).
Other than Japan, (Hitachi), any other countries producing compilers ?.

If they go with 'implementer defined' - there wont ever be OO COBOL
Open Source. One more nail in COBOL's coffin. Can you seriously perceive
"Java/C++ kids" - jumping for joy at having access to Open Source for
Procedural COBOL ? Meanwhile as COBOLers we can access their Open
Source, when available, including picking-up on GUI techniques/routines
- funny thing though, the developers who advocate this approach are the
same people who are adamant that COBOL should *never ever* have GUIs.

All the above aside, having read up Will Price on M/F and dotNet - I
have a clearer picture on Exception Handling. Doesn't quite fit what I
would like but I think I can do a mock-up using the existing M/F
Exception Handler class (primarily used for Validation checks as
described in M/F on-line). So I think I'm now able to make a suggestion
to J4 on how Exceptions could work in Standard OO COBOL - doesn't
compete with dotNet, and no reason it should - dotNet is unique to ONE
O/S - Windows.

Regardless of whether J4 goes for Standard CLASSES or Standard
COLLECTIONS - I feel in my bones we do need an Exception class for OO.
Whether the same techniques could be rolled-over to be be used with
Procedural code - I just don't know.

One thing I should add - I'm acutely aware of my own limitations and I
am extremely embarrassed that I'm the only one to raise this issue with
J4 - it is a large topic, which should benefit from more than one
person's input.

Still - would have been real nice if I could have generated a think-tank
here first to test my ideas.
/
/Jimmy

Relevant Pages

  • Re: Is Bill Klein a "hypocrite"? - asks Bill Klein
    ... Not answering a lot of this, but from what I heard BEFORE my J4 representation ... As far as any *current* public statement on implementation of the 2002 Standard ... Simple question - does M/F need the Standards machinery at this juncture? ... we get a handle on who is going to implement what of COBOL 2002, ...
    (comp.lang.cobol)
  • Re: cobol on pc
    ... LEAST since the '02 Standard was approved 5 years ago. ... I don't blame the vendors who walked. ... The only reason there is any kind of reasonable COBOL available today is ... IBM have a major legacy support committment that must not be eroded. ...
    (comp.lang.cobol)
  • Re: Are identifier names case sensitive?
    ... To avoid 'duplicates' of the M/F software it's a file COBDIR that you use to point both applications at the directory containing the M/F runtime support. ... I'd be curious, given say something like String2Num, written in COBOL and a comparative copy written entirely in Java, what would be the physical size of the respective packages - done in F/J or M/F you have to have the accompanying runtime etc.; presumably something similar even with Java. ...
    (comp.lang.cobol)
  • Re: diff between cobol1 & cobol3
    ... (The LANGLVL compiler option impacted this). ... Standard via the CMPR2 compiler option. ... supported Enterprise COBOL, support the '85 Standard *plus* the Intrinsic ... The current (Enterprise COBOL) no longer supports the CMPR2 ...
    (comp.lang.cobol)
  • Re: Can Open COBOL do this...?
    ... NOTHING that is called or is a "97" Standard. ... I believe Fujitsu have a COBOL product called COBOL 97 (It later became ... Pete - cast your mind back to SoftwareSimple - At one stage I suggested, that the then J4 could arrive at a common set of Collection/Dictionary classes, (and with no info on Fujitsu - there were no on-line manuals at the time), both F/J and M/F could adapt their classes, using PRIVATE methods to feed into the common standard. ... When it comes to support utilities/classes, as you've indicated for C# - 4,000 or was that 40,000, the M/F Collections/Dictionaries are a FRACTION of the M/F support classes. ...
    (comp.lang.cobol)