Cobol - COBOL Standards

Author

COBOL Standards

James J. Gavan

2007-04-19, 9:55 pm

Bill,

This is addressing your query regarding OO developers and your J4
document on where the Standards should go.

J4 Committee.
-------------
Back when it started COBOL had some 30 or more participants, vendors and
interested commercial users. Looking at the latest set of minutes issued
- J4 07-0072 - Meeting 260 - 2007 Feb 13 through 15, there were 4.5
attendees, (the 0.5 is if you include Chuck Stevens phoning in his
comments).

Now J4 has issued warning letters to Victor Consulting and Micro Focus
that their membership is in jeopardy if they don't attend the next
meeting. I suppose in the due course of time our Japanese friend, Wataru
Takagi will also soon receive a warning if he doesn't show up.

How difficult is it for J4 to get the message ? Like a sinking oil
tanker three-quarters submerged, the captain has ordered up four or six
deck-chairs for the wheelhouse, which is the only place still dry.
(Perhaps somebody should throw the deck-chairs overboard). Why was it
necessary for you to have to spell it out ?

Object Orientation

Not sure what was in your mind as to what you want to deliberate upon,
but see if any of the following helps. Firstly another quote from
Raymond Obin's 1993 paperback :-

-----------------------------------------------------------------------
OO is a very wide field, and there are many topics that can be
considered at the same time. This book is intended to be an introduction
to the subject for COBOL programmers. As an introduction , it is not
exhaustive, and for COBOL programmers it does not attend to matters
outside the COBOL arena.

Class libraries are a very important part of OO programming. Any set of
classes can be called a class library, although the term class library
is often often used to refer to a set of classes with a common theme. A
standard COBOL class library has not yet been defined....... For
more information on Class Libraries and for some insight as to what a
standard COBOL class library might contain, see Ref. *Smalltalk*. (***
my emphasis ***).

Programming tools are an essential part of OO programming, and are vital
if OO is to be used effectively. Class browsers, advanced navigation
tools, class librarian tools to locate classes that can be reused,
effective debuggers etc., are all part of the OO programming
environment. (*** Me, note well the following ***). When it comes to
selecting an OO language, the choice is likely to be swayed more by the
available tools than by the features in the language. What's the point
of an all-singing, all-dancing language it is practically impossible to
use ?

*** he then briefly mentions interoperability between languages and
CORBA ****

--------------------------------------------------------------------------------

Can't find the quote, but Ray must have been feeling in Heaven after a
few good shots of whiskey, because he adds later, "Perhaps one day we
will all be using OO COBOL".

I agree with him where the original intention seems to have been to
create COBOL OO support libraries and possibly at that time Ray was also
thinking of GUI classes as being part of that support. (???)

In support of Ray's statement it was another former M/F employee who
wrote to me about 5 years ago - 'He didn't have any faith in an OO
Language which didn't have support libraries'. He wasn't referring to
the M/F compiler, but OO COBOL in general.

Now it doesn't really matter which language you use, (Ray's reference to
all-singin' all-dancin'), the way to go is TOOLS. The first approach is
an IDE, then you hit dotNet with Visual Studio and get the features that
Pete enthuses about - depending upon the object or class you are using
it gives you a prompt list of available methods. (Interestingly enough
even the 'junior' Smalltalk, 'SQUEAK' has the visual presentation of
methods which can be used with particular objects).

Not quite in the same vein, but still tools, you will have noticed I
have enthused about M/F's Open ESQL Assistant which gives you
bullet-proof SQL statements. And you can use that tool as a complete
rookie to SQL. A lesser one but useful for a newcomer; write a
program/class accessing/updating an ISAM - have you got your comp-3
field values correct ? Shortcut, open the data file in the IDE and your
file format is shown USAGE DISPLAY, and can be edited, if you wish.

Bear in mind you could quite happily design a complete application with
Classes only or Programs/Classes, using Screen Section. And it would be
perfectly legitimate to call that an OO application. GUIs/Webbing are
add-ons and not the raison d'etre for OO. Xerox PARC Smalltalk team -
their first project was to design something we all take for granted - a
word processor. (I've mentioned before, what clinched it was when Adele
Goldberg secretively nipped their computers out of the building, having
first enhanced 'Smalltalk' with stick-men, graphical figures. Took the
equipment to a local junior school and the kids embraced it because of
the 'crude' GUI). It was the 'visual presentation', as with their word
processor.

Back to those three OO languages. Both Java and C# are complete
specifications. The simple reason - one party in *CONTROL* of the
design, not a bunch of competitors without the willingness to share
ideas. Sun Micro Systems for Java and Microsoft for C# - they specified
what they wanted, obviously getting user input, and without
interference, produced the respective languages.

Now Microsoft has the edge over others because the dotNet approach,
Visual Studio, allows them to add tools as they see fit. Tools could
never be a function of a COBOL Standard, but certainly support classes
should have been. (I'm not familiar with Java but I think there are
several 'IDEs' available, so perhaps they offer a similar approach to
the M/S Visual Studio, or could). The F/J and M/F IDEs certainly include
the use of tools, but rather than each updating and re-inventing the
wheel they have opted to support dotNet.

Smalltalk - it does the job but it's a bit of a mish-mash like COBOL.
Their ANSI specification was Smalltalk 80 which spelled out syntax usage
and provided the basic framework for class libraries. There is no such
thing as a Smalltalk 80 compiler. But based on that spec there are a
few/several compilers with two major leaders in the commercial world;
Dolphin has its own newsgroup and the developers appear fairly 'active'.
As a freebie there is SQUEAK, but the feeling I get is it wont cut it
for commercial applications. As Adele Goldberg wrote in another text,
"...there are various compilers and adhering to Smalltalk 80 syntax,
each vendor has produced thousands of support classes". My observation -
presumably they are using compatible method names, which in theory at
least should make it possible to switch from one Smalltalk to another.

Over and above that, in the case of Dolphin, I have noticed developers
make queries. These have been answered by the vendor with a suggested
solution from existing methods, or 'Good idea, we'll put that on our
wish-list". The items in the wish-list appear in their next Fixpack.

OO COBOL -

The J4 specification certainly provides the basic bread and butter
formats to create Classes - Factory, Object Section, instantiation etc.
To date I can't think of anything I would want added to the J4 spec,
except for what follows.

The Standard has three pre-defined objects, Null, Self, and Super

Micro Focus has an additional 'SelfClass' ( which might be clearer if it
had been named 'SelfFactory' or 'SelfStatic'); the purpose being to
allow Object Instances to invoke Factory/Static methods. Fujitsu appears
to have something similar, 'Class of Self' etc., but you make specific
entries for those as 'Usage object reference....'.

No matter, the world isn't going to fall down if 'SelfClass' is never
part of the official language.

What we have to date is a refinement of the original OOCTG
specification, and in all probability, by team members who had knowledge
of other OO languages. Similarly the three authors I continuously refer
to, Ed Arranga/Frank Coyle and Will Price - before they tackled OO
COBOL, they each had a background of using and teaching Pascal. I may
well be wrong, but I don't get the feeling that anybody on the J4
existing team has that expertise - i.e. that they code OO COBOL for a
living. (I was coding OO COBOL for about a ten year period and I
certainly don't consider myself to be an expert).

Procedural COBOL is not an insurmountable problem to a programmer with
3-5 years experience. Throw a new procedural feature at a group, such as
John Piggott's Dynamic W/S Tables, most, if they have the patience to
read the specification, can understand it and contribute their two cents.

Not so with OO. Yes you need the syntax to get off the ground, but it
isn't the syntax that determines how it is used. It's all about
Concepts, and although somewhat overblown you also need to consider
Design Patterns which Charles recently made reference to about learning
Java. J4 is very good at dotting the 'i's' and crossing the 't's', but
that approach doesn't solve OO design.

A simple example; I suggested that the word 'callback' should be
retained, as it was used in several languages, instead of calling it an
'iterator'. Our favourite wordsmith Chuck Stevens hit the English
language dictionaries for an accurate definition of the two words -
conclusion, we, (J4) will go with 'iterator'. No big deal.

However, only yesterday I decided to check both words out in a
programming context :-

http://en.wikipedia.org/wiki/Iterator
http://en.wikipedia.org/wiki/Callback_(computer_science)

- they certainly appear to have a subtle, but different meaning to me,
and a callback does include iteration. Check the two references and see
what you think.

Collections/Dictionaries
------------------------

The most charitable thing I can write at this stage is that this feature
is ill conceived. It doesn't come even close to what Ray Obin in the
OOCTG team envisioned back in '93. Micro Focus produced EXACTLY what Ray
conveyed about class libraries. Fujitsu did the same but not quite to
the same extent, producing classes for Collections/Dictionaries only,
i.e. a pared down 'string handling library'.

In addition to the character/array/collection handling they provide
Micro Focus have also extended their libraries to include Java and OLE
support and no doubt there are probably further classes added to Version
5.0 to deal with dotNet. (Possibly likewise with Fujitsu to operate with
dotNet).

It's rather interesting, (I can't recall the topic, nor understand the
solution :-)), but Michael W. illustrated that COBOL was not a good fit
for the particular problem in the M/F Forum. He illustrated it with a
COBOL example. The result was gawdawful, not because of Michael's
approach, but because of tables and tables of Hex values required to
achieve the result. Hasn't been a comment here in CLC for years, but a
phrase that used to pop-up was, 'Use the appropriate llanguage for the
problem'.

And of course as part of their OO packages both M/F and F/J introduced
GUI modules.

Given that COBOL *did* have comprehensive support libraries then perhaps
it could have been reasonably coded as an OO solution. Similarly, why
reinvent the wheel for forecasting. Given that there had been a common
class library across COBOL OO implementations, then a third party with
real know-how on forecasting could have produced a Forecasting library
for re-sale. Under the wraps that package would have invoked numerous
methods from the standard COBOL libraries.

During the timespan that J4 has been figuring out TRs for Finalizer,
Collections, Dynamic W/S Tables, both M/F and F/J have moved on in the
world - dotNet.

Could we now have COBOL Class Libraries. For starters, much too late and
developers will have already looked elsewhere. It would require
miraculous' co-operation between competitive vendors, plus of course an
army of monkies to figure it all out. The TR for
Collections/Dictionaries which merely specifies :-

OrderedCollection
SortedCollection
KeyedCollection
ExceptionHandling
Iterator

has taken since the year 2000 onwards and the earliest implementation,
(if their is a vendor daft enough to use it), will be 2008.

WHITHER and HOW
---------------

I took a look at the following and gave it two reads ;-

http://www.cobolstandard.info/j4/files/07-0064.doc

I agree with your paper but would question the last two paragraphs of
your EXTREME SOLUTION :-

---------------------------------------------------------------------------
10) Add a “statement of direction” to this revision indicating that it
is intended to be the LAST full revision of the COBOL Standard and that
it is intended to be placed into “maintenance” mode soon after approval.

11) Include another “statement of direction” indicating that although
this standard is viewed as the culmination of the COBOL Standardization
process, individual implementors are expected to respond to their
changing IT environments and user needs and desires, and provide future
enhancements to the COBOL language. (*****) When/If there appears to be
a new feature or features that have significant user demand AND that
implementors are creating multiple solutions for, SHOULD there be
ADEQUATE resources, then a future TR, Amendment, or other document may
be created. However, this would require more development resources than
are currently available to the COBOL standardization community.
---------------------------------------------------------------------------

Paragraph 10
------------
By revision you mean the items currently outstanding, including
the TRs, presumably with an optimistic date of COBOL 2008 ?

Step 1 - which vendors on the committee are committed to implementing
perhaps 'some' of the features ?

- Acu - a 'marriage of convenience' to give Don Schricker a job
- IBM
- Micro Focus - if they don't get their pink slip first

Step 2 -

What about Acu, Hitachi, Liant(RM/COBOL), Unisys and the 'open source'
boys ?

Is it worth pursuing the outstanding list. Not too much effort to reduce
those 4.5 attendees to 3 - who is going to do what ?

Unpalatable as it may be to those J4 members still hanging in there, the
reality is, that we should call it a day and state :-

" COBOL 2002 is the LAST COBOL Standard and includes Object
Orientation, but does not include class support libraries".

Don't like the word 'LAST' in that sentence; then use 'DEFINITIVE'. It
says the same thing in a shrouded way just as 'surge' is a neat way of
saying 'increase by x thousand troops'.

Note : there are two groups of OO languages - languages WITH and WITHOUT
class support libraries - see :-
http://en.wikipedia.org/wiki/Catego...mming_languages

Accepting the reality, is that so dreadful ? The last Smalltalk Standard
is dated 1980, and it works just fine. As Michael W. noted, Smalltalk
lacked success because of non-existent marketing.

Paragraph 11
------------

The last part of Paragraph 11, where I have added the asterisks - I just
don't think it will work. You and I dream up a real exciting
gizmo/feature which we suggest to our compiler vendor - they embrace it
enthusiastically and depending upon its complexity it may take them 6
months or perhaps a year before they formulate the feature and add it to
their next version of their compiler - and it works smoothly. They
suggest the proven enhancement to J4. Now the fun begins. Tom, Dick
and Harry, (and Harry is from one of the vendors who has NO intention of
implementing it anyway - and it also assume there IS a third person on
the committee called Harry !), put in their two cents, and J4 eventually
specifies or produces a TR for the feature - the chances are the only
commonality the new TR has with the original proposal - it has the same
subject title !

Above are examples, but now a real one. (Like Pete, I personally don't
see a need for a separate COBOL XML model - but nevertheless, as an
example). So Micro Focus dreamed up a new feature for XML. I haven't
read up on it. First bit of nonsense I saw tucked away in the J4 minutes
that somebody, obviously in a fit of pique, demanded/requested that Don
Schricker go back to CEO Tony Hill and get confirmation that Micro Focus
would not claim copyright. (Politics has been with COBOL since Grace
Hopper's days). What bloody nonsense - how can you possibly offer
something to a group and as an afterthought claim copyright. Add to the
above your own comment that although the topic is XML, there is a
difference between the J4 spec and what Micro Focus already uses.

We know the lurkers will read this. Yes there are current and former J4
members who worked damned hard to give COBOL what it has. They got
either enmeshed in or created the internal bureaucracy, (over and above
any bureaucracy required by ANSI), that has made COBOL enhancements so
slow to happen. To be fair, if your number of warm bodies on the
committee keeps on sliding down to a total of zero, how can you handle
numerous topics anyway. Sorry folks in the days of reality TV
shows, you just haven't listened to what's going on around you, but
perhaps worse, haven't even taken notice.

Jimmy

James J. Gavan

2007-05-17, 6:55 pm

Further to my previous message about COBOL Standards, I'm highlighting
the following WITHOUT comment :-

J4/07-0071 - Draft Minutes of Meeting 261 for Apr 16 - 20, 2007.
-------------------------------------------------------------------------------------------------------------------------------------------

13.2 Planning for WG4

13.2.1 07-0064 - Resources, responsibilities and priorities (Klein)

The committee directed Ms. Bennett to prepare a document addressing
status, resources, and options for COBOL standardization efforts.

Mr. Schricker will prepare a liaison report from J4 to WG4.

J4 recommends that the following features in the 2002 standard be made
optional:

· report writer

· validate

· standard arithmetic (as in the 2002 standard)

· screen handling facility

J4 recommends that the following new features of the current draft be
optional

· collection classes

· finalizer

· dynamic-capacity tables

J4 recommends that the following new features of the current draft be
kept as core features:

· XML

· any-length elementary items

With respect to method overloading, J4 recommends it be retained in the
draft.

---------------------------------------------------------------------------------------------------------------------------------------

Pete Dashwood

2007-05-17, 6:55 pm

"James J. Gavan" <jgavandeletethis@shaw.ca> wrote in message
news:KV13i.191791$aG1.172361@pd7urf3no...
> Further to my previous message about COBOL Standards, I'm highlighting the
> following WITHOUT comment :-
>
> J4/07-0071 - Draft Minutes of Meeting 261 for Apr 16 - 20, 2007.
> -------------------------------------------------------------------------------------------------------------------------------------------
>
> 13.2 Planning for WG4
>
> 13.2.1 07-0064 - Resources, responsibilities and priorities (Klein)
>
> The committee directed Ms. Bennett to prepare a document addressing
> status, resources, and options for COBOL standardization efforts.
>
> Mr. Schricker will prepare a liaison report from J4 to WG4.
>
> J4 recommends that the following features in the 2002 standard be made
> optional:
>
> · report writer
>
> · validate
>
> · standard arithmetic (as in the 2002 standard)
>
> · screen handling facility
>
> J4 recommends that the following new features of the current draft be
> optional
>
> · collection classes
>
> · finalizer
>
> · dynamic-capacity tables
>
> J4 recommends that the following new features of the current draft be
> kept as core features:
>
> · XML
>
> · any-length elementary items
>
>
> With respect to method overloading, J4 recommends it be retained in the
> draft.
>
>
> --------------------------------------------------------------------------------------------------------------------------------------

While I admire your restraint, Jimmy, I'm certainly going to comment... :-)

It is becoming perfectly obvious that features proposed by the J4 Chair
will be "recommended" for incorporation. Everything else is not important.
This same Chair accepted an award for delivering the 2002 COBOL standard
only 17 years late, when an honest person would have declined and apologised
to the COBOL community.

Perhaps I would be less cynical about this if there had been some
explanation as to why the above choices were made. Of course, if you don't
have to answer to anyone, then there's absolutely no need to explain
yourself.

Bit like Mary Poppins, really... ("I never explain anything"). Fine, if
you have mastered sliding up the banisters or floating away on an umbrella
when the wind changes; not fine if you haven't.

Pete.

Rick Smith

2007-05-18, 3:55 am

"Pete Dashwood" <dashwood@removethis.enternet.co.nz> wrote in message
news:5b433uF2qk6lqU1@mid.individual.net...
[snip]
> This same Chair accepted an award for delivering the 2002 COBOL standard
> only 17 years late, when an honest person would have declined and
apologised

Mr Dashwood, you seem to be using an idiosyncratic
definition for "late", or you misspoke.

Work for the 2002 standard appears to have begun
around 1991-1992 and was initially scheduled for
release in 1997. (That is only five years late by my
reckoning.)

However, as I understand it, the object-oriented
features were initially based on Smalltalk, which was
not approved as a standard until 1998; but some,
I believe, wanted more compatibility with C++, which,
also, was not approved as a standard until 1998.
(That suggests no more that four years late, if one can
be satisfied only with instant gratification.)

I believe that, as a practical matter and considering
all that was added, the 2002 standard was not late at all.
And, considering the problems I have seen with that
standard (remember that I have been diagnosed with
OCD), I feel it may have been released a bit early. <g>
[There are more than 50 defect reports and a number
of editorial corrections for the 2002 standard.]

Rene_Surop

2007-05-18, 3:55 am

This is really a place (comp.lang.cobol) to post the J4 minutes of
meeting. And a comment or two will do. At least now we knew probable
sentiments of "non-attendees".

Rene :)

Pete Dashwood

2007-05-18, 3:55 am

"Rick Smith" <ricksmith@mfi.net> wrote in message
news:134q48p9vt2a647@corp.supernews.com...
>
> "Pete Dashwood" <dashwood@removethis.enternet.co.nz> wrote in message
> news:5b433uF2qk6lqU1@mid.individual.net...
> [snip]
> apologised
>
> Mr Dashwood, you seem to be using an idiosyncratic
> definition for "late", or you misspoke.
>
> Work for the 2002 standard appears to have begun
> around 1991-1992 and was initially scheduled for
> release in 1997. (That is only five years late by my
> reckoning.)
>
> However, as I understand it, the object-oriented
> features were initially based on Smalltalk, which was
> not approved as a standard until 1998; but some,
> I believe, wanted more compatibility with C++, which,
> also, was not approved as a standard until 1998.
> (That suggests no more that four years late, if one can
> be satisfied only with instant gratification.)
>
> I believe that, as a practical matter and considering
> all that was added, the 2002 standard was not late at all.
> And, considering the problems I have seen with that
> standard (remember that I have been diagnosed with
> OCD), I feel it may have been released a bit early. <g>
> [There are more than 50 defect reports and a number
> of editorial corrections for the 2002 standard.]
>
>
>
I'm calm now.

(It doesn't take 17 years; just the realization that I'm getting

pointlessly...)

Pete

2007-05-19, 3:55 am

Rick Smith wrote:
> "CG" <Carl.Gehr.ButNoSPAMStuff@MCGCG.Com> wrote in message
> news:62051$464e1d05$4275f8e1$496@FUSE.NET...
> standard
>
> Until Bill responds, ....
>
> These are the dates for COBOL 85 major
> and minor revisions: COBOL (ANSI X3.23-1985,
> X3.23a-1989&X3.23b-1993), as recognized by
> FIPS. Note the four year pattern for the minor
> revisions. The next scheduled revision was the
> major revision for 1997. This is the revision that
> was delayed until 2002.
>
> It is my understanding, from prior discussions,
> both on this newsgroup and documents posted
> to the J4 web site, that a revision is "generally"
> required every five years; but such a revision may
> include a "confirmation" (or such) of the standard.

I'm not sure which was which, but I believe the 1989 document was called
the Corrections Addendum and the 1993 document was the Intrinsic
Functions Addendum. [I may have them reversed.]

This was, I believe the first time the term Addendum was introduced into
the standards process. And, I think the motive was that, considering
how long it took to get the 1985 Standard published, no one was ready to
open the base work to a full review. It was important to get the two
sets of changes out ASAP.

Again, I'll defer to Bill for any corrections to my recollections.

Carl

William M. Klein

2007-05-21, 7:55 am

<Bill was "out-of-town" with limited internet access - and will be leaving again
on Wed. It will take me a while to figure out "what" to respond to on "late and
timing of COBOL Standards">

One "bit of news" related to a comment about the "chair" of J4.

I do NOT have all the fact yet, but what I do know:

A) Acucorp and Micro Focus used to both be on J4 (as of the last meeting) and
Don Schricker was the Acucorp rep - and the J4 chair

B) Micro Focus acquired Acucorp

C) The two reps for Micro Focus do NOT include Don Schricker

D) Don Schricker previous "plans" to attend the WG4 meeting in June in the UK
appear to be "off"

E) The position of "chair" goes with the person, not the company he/she
represents

F) As of this exact minute I have NOT heard of any other organization joining J4
or of a "call for new chair". I would expect one of those two things to happen
at some time relatively soon (or that Don will become the alternate for one of
the remaining 3 - other than Micro Focus - US domiciled members of J4).

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

Sponsored Links