Re: Micro Focus position on the "Standardized" OO Collection Class

Fredrick.Underwood.Devrie@gmail.com wrote:
> William M. Klein wrote:
> 

Hey ! Hey ! What's all this haranguing Bill Klein for. Don't shoot the
messenger !

For the record, way beyond retirement age, I have given up on
programming completely, particularly COBOL because it is becoming
prohibitively expensive on PCs. However I am a thousand percent for OO
COBOL and the feature I enjoyed most was Collections/Dictionaries.

Background - Ann Bennett/Wallace representative for IBM on J4 and at the
time Covenor for WG4 (ISO), which job she is probably reluctantly
volunteering for again, now that Chuck Stevens (Unisys) got laid-off,
credits three people with "giving" COBOL any OO capability - Raymond
Obin who was at the time an M/F employee, somebody from HP and the third
company representative I can't remember.

Back around '93, J4 set up a sub-committee OCTG (Object COBOL Technical
Group). Good move. People who had a genuine interest in pursuing the
topic, even if they weren't all closely familiar with it. Ray Obin
produced a short paperback summarizing their thoughts and current OO
classes are not dramatically different, although there have been minor
refinements made to the syntax. (I'm not referring here to either
Collections or GUIs which were not at that time part of their
objective). Amongst others, in his book Ray acknowledged two M/F
employees at the time, Don Schricker and Bill Klein, who served on the OCTG.

Frankly it's a bloody miracle COBOL ever got any OO at all - just note
all the people in this Newsgroup oozing with enthusiasm !

Four companies took up the challenge, Hitachi, IBM and Micro Focus.
The fourth, Fujitsu followed a while later. IBM had Visual Age closely
tied into OS2 - and as we know that appears to have silently
disappeared. For Fujitsu, Hitachi and Micro Focus to produce
competitive OO compilers versus other languages, they knew they had to
provide two features - GUIs and Collections. They each did this in their
own way. It's always been a mandate of J4 that the COBOL Standard should
not acknowledge different Operating Systems. My thoughts, bad move - and
throws Windows GUI-ing out of the window (no pun intended).

I rile each time I reflect on this. Back around 95/96 Russell Clarke,
(Australia) produced a very DETAILED paper on OO COBOL Collections -
well in excess of 50 pages - I'll take a guess, it took him at least six
months of thought to put it together. I'll admit I didn't comprehend
clearly what his paper was about - and I'm just as certain that 90% of
the J4 membership didn't have a clue either ! Having given it subsequent
thought, the only way to discuss Russell's paper was that it produced
many templates which allowed you to cobble them together to achieve the
particular collection type you required to suit your own needs.

Had he had sufficient time, maybe his ideas might have come across more
clearly if he had taken those templates and produced samples showing what
you could achieve by 'cobbling'.

It appears J4 thought Russell's paper was the best thing since sliced
bread. Without catching their breath they forwarded it to WG4 for comment
- where it got CLOBBERED on some nitty-gritty stuff. "Ooh!", said J4,
"Good try, but let's put it on ice". Meanwhile some of the OO books were
telling us there would be OO Collections around '97 - the authors got
this info from J4 membership.

Back to William Klein. Henry VIII's 'Defender of the Faith", on British
coinage. If there's anybody deserves that awarded in the COBOL world it
is Bill. He served on J4 in a private capacity (picking up the tab for
membership and travel expenses out of his own pocket). He has always
been a staunch promoter of COBOL and no less for OO. He is on record as
writing, "We want OO COBOL (and Collections) to be the best there is".
Having said that, I think I'm correct in stating that Bill is still not
an OO enthusiast - but from his view, if COBOL has to have OO then 'make
it the best'. So far as I am aware he has never made comment one way or
the other that he is for or against Collection classes.

Back to Russell - Thane Hubbell who subsequently represented Fujitsu on
J4 until they quit, set up a discussion group, roughly some 20 of us. So
somewhere around 2000 Bill points us at Russell's document sat on ice.
Even though a couple of us had earlier volunteered to give some input,
we were not advised by the J4 chair that Russell's paper existed. There
was something written in J4 documentation that in due time they would
return to the Collection topic. Bill nudged them, at the same time
pointing us at Russell's paper. I'm quite sure that the J4 team were
delirious that Bill raised this old nugget.

With an interest in Collections I had a deep look at what Russell had
written. For clarification I contacted him but had an out-of-date e-mail
address. So now I sat down and produced something for J4 based on my own
coding using M/F classes. It wasn't a proposal, but a description from a
developer's point of view. (A subtle way of telling the 'non-knowing'
what OO Collections were about).

I consider it absolutely C-R-I-M-I-N-A-L the way Russell's paper was
treated. Having consumed a considerable amount of time in producing his
paper and the currency he was paid in was fresh air. So they just
shelved it. Not that Russell could give a monkies; soon after he
switched completely to Java - as advised to me when he acknowledged my
e-mail, (see next para but one below)..

By no means comprehensive, and perhaps simplistic, I arrived at a
different model from Russell. On reflection, if Russsell's paper had
expanded on his proposed syntax with examples, it might have been a
winner. Lots of classes involved but I think he had all points covered
and conceivably it might have been considerably more flexible than the
Smalltalk model on which Hitachi and Micro Focus based their
collections. (I'm referring to what you called a 'Tutorial Language'
Pete :-) ).

Just about to submit my initial paper, out of the blue comes Russell - he
had picked up my message from his old e-mail address. He made some
useful comments and agreed that he had missed out on not including
SORTED COLLECTIONS. Too late in the day to revamp what I had written I
submitted it to J4 with some of Russell's responses as an appendix. Let
me state again, emphatically, I am no OO expert, just somebody
illustrating the code he produced using existing M/F classes.

Forgotten the timing, when it started, but OO Collections were
'resurrected'. Enthusiastic and the new boy on the block, (the J4 team),
Thane Hubbell was either asked or volunteered to do the Collection
proposal. Features began to appear, but didn't convey the whole story.
Off the top of my head there are some 30 plus classes in the M/F
Collection hierarchy - things like CharacterArray and Arrays which can be
used independently - e.g. to access the icons in a Treeview you use an
indexed collection held in an Array.

Well he sure took the knife to the M/F structure. Whether at the time
Thane had *actually* coded in either F/J Collections or Java - I don't
know. The net result first go-around was Ordered Collection,
KeyedCollection (aka Dictionary or MAP in Java), with coded examples of
methods. (Note I capitalized SORTED COLLECTIONS above ?). I referenced
Fujitsu on-line manuals but unfortunately examples only show snippets of
code - not complete programs/classes. They sure have a different
philosophy about creating object references compared to M/F. Using the
'Design Pattern' technique read a record from a file into a new
class(object) for that record - now you have an object reference - as
opposed to M/F where objects can certainly be created using aRecordClass
but also the ability, say for collections, to have them as 'text
strings' (ofValues) or displayable elements (ofReferences) to display GUIs.

I'm still waiting for the penny to drop - then eventually XXXXX, "What
about bloody SORTED COLLECTIONS ?", which from experience were 80% of my
usage. No acknowledgment but then a Sorted Collection class appears
together with an OO Exception Class.

Fed up at this stage and not seeing any apparent input from Micro Focus,
I wrote to Tony Hill the M/F CEO. (He's now gone). As I wrote just
recently his reply, "What do you want me to do ?". I *did* have thoughts
- "Tell J4 to stick their Collection structure where the sun don't shine
!". Whether he passed my comments onto any of his lieutenants, I don't
know. (To be fair, Tony was the CEO and it would be wrong of him to get
involved in the daily nitty-gritty. His prime job was keeping the
shareholders happy - MONEY).

Now back to the J4 Collection Structure. Paraphrase the whole game so
that you have a limited number of classes and down the road you have
'new' problems. (From a Sun Microsystems book, they took two shots at
the Java collection structure to get it right).

Now let's talk the 'real world' using a Procedural W/S Table occurs 'x'
to 'y' depending on 'z'. Can you visualize where such a table would
contain elements for info on Customers, Vendors, Products and say
Weather forecasts. The sensible approach would be four W/S Tables where
you can recognize each individually.

But now J4 has minimal collection classes, so part of the thinking is
'You'd better allow for a collection to hold different types of objects.
What a wacky solution, because you still have to figure out which is
which. Just so happens, Smalltalk and M/F have the class BAG - a
grab-bag. You want to temporarily collect a Customer name, a dozen eggs,
bicycle repair kit, or whatever and you store them as a 'temporary
holding pattern' in a BAG. Logically M/F Collections refer to one type
of object. OK, if you were assembling a p;purchase order (like
Amazon.com) you might have *associated* records, each identified by
(Record) Type, for Customer Name and Address followed by a series of
books or CDs being ordered. Thinking you have done the smart thing by
minimizing the number of class types is not necessarily a good way to go.

PART 2 - The Money World

You and I program to make a living. hardware and compiler vendors also
want to make money. As Bill has indicated in this Forum, many times, he
is extremely doubtful that compiler only vendors can survive in the long
term - and here we are talking about all the COBOL PC compilers.
(Regrettably Chuck Stevens just got laid off from Unisys - and they are
big iron trying to compete against Big Blue).

You can't do it (PC-wise) just charging developers say $3,500 for their
initial purchase. Say there are 23,000 developers x $3,500  - nice gravy
$80.5 million but that's a one-shot deal. So one way or the other they
get innovative in achieving additional income, and that means
independent developers having to spend more.

DotNet. My understanding is that M/F was initially approached by
Microsoft and turned Bill Gates down, even though they had a good
relationship. Fujitsu jumped into the gap - then quit J4. To be
competitive M/F had to do likewise introducing dotNet with Net Express V
4.0.

As Bill has previously indicated M/F did some pruning probably based on
realistic projections. Firstly Tony Hill left. Then Don Schricker who
was the M/F J4 rep. Little surprising that they would let a key man of
theirs go who has been on J4 almost as a career.

While M/F continuously updates the class structure with each
Fixpack/Upgrade covering OLE, Java etc., nevertheless they ask
themselves how can we reduce our development costs. Well the dotNet
approach is a nice let-out. I don't know whether or not M/F users have
moved in droves to dotNet but I see questions, in the Forum, coming up
more frequently about using the dotNet feature to get at other
languages. Personally I think dotNet is a bit of a death-knell to
PC-COBOL for any vendor. Developers will get the message that by taking
the plunge and getting into other languages they can do all they want.
The next observation is "Why use COBOL at all ?". I know of three
competent OO COBOL programmers who have already arrived at that
conclusion - and they aren't going at dotNet via Net Express !

You use the word STUPID below, so you have in effect already said it. I
wont use the same word back to you - but view what I've written above
and translate your ideas into REAL DOLLARS (OR POUNDS) on behalf of
Micro Focus. I would love it if COBOL had Standard Collections and GUIs
- the latter is definitely never going to happen. Money-wise M/F have
concluded that a revamp of their PROVEN and WORKING Collection structure
just doesn't warrant the cost.

It is NOT as you suggest Bill's position. Having within perhaps the last
month or so discussed his representing them on J4, (Hope they are
picking up the tab for expenses Bill :-) ), he has asked what M/F's
position is on various features not yet implemented. He is the messenger
- passing on their official position; he has no personal axe to grind.

Unlike most of the legalese garbage that occurs in J4 documentation -
Bill's message was clear and precise on behalf of the client he
represents. "Duel ?'. 'Uncivilized ?'. Get real ! Like it or not we live
in a rotten world where gentility has gone by the board. Sadly it's the
bucks that count.


> 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.

What bloody portability ? That went out of the window after COBOL '85.
Have you used M/F support classes. To comply with what you are
suggesting not only would M/F have to revamp every affected class but so
would I, where I AND THEY use pic x(4) comp-5 !
>
> 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.

Micro Focus have woken up to the fact that they are not making as much
money as they would wish. Take it this *really* is their official
position. As to losing some customers perhaps - but not the way you are
suggesting - try the dotNet route instead.

A quote from Bill's reply to you :-
.....................................
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).
....................................

I can only guage by what I see in the M/F Forum. My best guess - in
excess of 90% of people using the Forum depend upon Dialog System -
which has canned templates to handle each of the Windows controls.
Bill's comments kind of cement that observation.

I only know of some five M/F users who truly use OO - and of those two
have gone the dotNet route without using COBOL !

And when it comes to OO, want to run down the list, not sure if I have
them all :-

- Acucorp - niet to date

- CA-Realia - ? Not likely. They will point you at one of their packages
other than COBOL

- Fujitsu - yes but also dotNet. They've quit J4. Will be interesting to
see if they switch to the J4 Collections. Likely because
of dotNet they will leave their own Collection code
untouched.

- HP - Probably niet. They quit J4

- IBM - well, via JavaBase

- KOBOL - no mention to date

- Micro Focus - yes but also dotNet

- RM/COBOL - Niet

- Unisys - Niet

- Open Source - Ahhhhhh. Let's gear ourselves to COBOL '85 . It's only
21 years-old technology

-----------------------------
Your other message - you are out to lunch.
 
member of the user 
actual 
>
>
> Your experience is obviously limited.  I have ported many systems
> across multiple platforms and vendors with minimal change.  This is
> quite a bogus argument.  It is partially because of standardization and
> conforming compilers that this is possible, and that COBOL is the
> success story that it is.  I am even aware of systems developed with MF
> COBOL but deployed with a different vendor COBOL (with ZERO source code
> changes) in order to avoid paying out of sight run time fees.

You've got your eyes wide shut on this one. So you've ported to other
COBOLs. How many M/F extensions (and BLOODY USEFUL extensions) did you
chop out to achieve portability. And surely you are referring to
Procedural COBOL, not OO which this is all about. Did you try to port OO
code - what exactly did you do with pic x(4) comp-5, consistently
referenced using GUIs and Collections in M/F ?

Back in Thane's discussion group, Pete Dashwood made reference to pic
9(09) comp-5 a feature of the as yet unpublished Standard, available in
Fujitsu and certainly available in M/F. Seemed Pete made a sensible
comment so I switched all my programs from  pic x(4) to pic 9(09)comp-5
- and finished up with an unmitigated disaster - I had to switch the
programs back to pic x(4) comp-5. (And while the Standard acknowledges
comp-5, would it have been a big deal to have allowed pic x(4) comp-5 as
a short-cut ?).

I don't know if I have ever said this as bluntly before - but where M/F
is concerned, with no proof, I get the impression others on J4 are just
out to screw them on some of their innovations.

(BTW I *do* like avoiding the runtime fees - but what am I supposed to
do, drop OO to achieve this ?
>
> 
amount of 
Windows, Unix, 
Therefore, as stated 
(RESTRICTED to COBOL) 
>
>
> This is such a spurious argument it makes me laugh.  Of COURSE there
> are few OO only COBOL programs in MF Experience.  They don't have a
> conforming implementation of the standard so there cannot be any
> programs that are OO only.  It's like arguing against developing a
> hydrogen powered car because you have never developed a hydrogen
> powered car.  MF obviously wants the standard to be whatever THEY have
> developed and not a REAL standard.  I am aware that MF has OO
> extensions.  Compared to the COBOL standard, they are, well - just
> aweful.  Their ISO2000 directive that allows comforning syntax is ly
> incomplete and if it WERE then it would be possible to write full OO
> COBOL programs and who knows ... if there were a way to do it maybe
> they would encouter users using it!
>
Got news for you. I used to code SOLELY in OO classes with the exception
of the Procedural Trigger program. As indicated earlier, please bear in
mind the "OO-four" produced OO compilers while J4 sat upon their hands,
way before there was a Standard. Your reference to the ISO2000 directive
is correct - it is purely cosmetic to get the 'look and feel' of the
Repository syntax. No point in belabourig that point, if you want
Repository get N/E V 4.0 onwards.  (The thing to really note about that
Directive is that it was an attempt by M/F to comply with the latest
deliberations from J4. Note the year of the directive 2000 - it took
until COBOL 2002 before we had the Standard that his directive was aimed
at, as an interim. Went checking to try and find when the directive was
first introduced - let's go with '97 (97 to 2000) as opposed to actual
('97 to 2002).

To check went to Will Price 'Elements of OO ' First Edition, published
1997. Didn't confirm introduction date for that directive, but in doing
so turned up this :-

"Figure 10-7 is a hierarchical list of collection classes of the
Standard collection class library as described in a March 1996 ISO document.

Collection
Bag
Identity-set
Identity-table
Identity-dictionary
Value-set
Value-table
Value-dictionary
Sorted-set
Ordered-set
Ordered-table
Ordered-dictionary
Ordered-collection
List
Queue
Stack


Without repeating his diagram for the M/F grouping, with name changes,
it is fairly close.

So who got it right ? (a) J4 who passed the above on to WG4 in '96,
which M/F fairly closely emulated, or (b) J4 after the year 2000
dreaming up an entirely new set ?


As to Micro Focus doing their own thing - based on what were perceived
as firm upcoming J4 changes, M/F added features in advance (Procedural,
not necessarily OO). As Bill pointed out quite a while back, they got
burned on this one; somebody at J4 managed to put a little twist on the
new feature which screwed M/F. Possibly the enhancement may even have
been canceled.

Let me emphasis this is not in support of M/F - they can look after
their own bailly-wicket. Just my perception of the current state. Yes it
most certainly is in defence of Bill, who has always been of the frame
of mind taking an impartial look to get the best out of both Procedural
and OO COBOL - not that he actually needs defending; he is quite capable
of doing his own thing. I just don't like to see him inaccurately maligned.

Believe me I am truly pissed off at costs and runtime fees - which
contributed to my giving up on the programming game !!!!

Jimmy