[Cobolforgcc-devel] COBOL'ers of tomorrow - PLEASE read and act now !!

[William M. K. <wm...@ix...>]

FYI - I just posted the following in the comp.lang.cobol and IBM-MAIN
newsgroups.

-----Original Message-----

If you think that COBOL may be in your future (your shop's future, or even
creating your paychecks <G>) for the next few years, please read the
following AND act upon it.

The FCD (Final Committee Draft) of the next COBOL revision is now available
and desperately (IMHO) needs reviewing.

You can get a copy (download) from:

     http://www.ncits.org/tc_home/j4.htm

Look for the line:

 COBOL FCD (6.8 MB) or  Compressed Self-Extracting File (2 MB)

Time is OF THE ESSENCE in reviewing this document and getting your input
(good, bad, whatever) to the appropriate people.  The official "review
period" will begin (unless something changes between now and then) on
February 1, 2001 and last 4 months (internationally) but only 3 months (for
US Public Review - subject to possible modification).  I will point "you
all" to the official Press Release when it becomes available - but I wanted
to give a "heads up" as soon as this document became generally available.

If you are in the US (or wish to submit your comments via US-only channels),
then you will need to send them to NCITS - details on how to do this will be
in the Press Release - when available.

   HOWEVER,

if you do not live/work in the US and/or are a citizen of another country
and are interested in submitting your comments thru your own (non-US)
national Standards body (and I strongly, STRONGLY recommend this), then go
to the following page to get "contact information" - and find out ASAP how
and when they will be taking comments:

 http://www.iso.ch/addresse/membodies.html

  ***

So much for "preface" - now let me make some suggestions (and these are ONLY
personal opinions) on how and what to do for your "personal" review of what
will happen to COBOL in the near, medium-near, and somewhat far futures.

Step 1: (critical)
  Contact your COBOL compiler "vendor of choice".  Find out:
    - how much resource THEY are spending on reviewing this document - both
for its "ease" of implementation - but also for any compatibility issues tha
t it will be causing THEIR customers
    - what their current position is on whether or not they think they will
ever implement this version of COBOL - in part or whole.  Let them KNOW
whether or not this is important to you - and how much you will PAY for it.
    - whether they (the vendor) or any of its user groups plan on providing
"consolidated" input to the review process.

(If they aren't reviewing this document now, you can be pretty certain that
either they won't be providing a conforming compiler in the short-term - or
that you and they will BOTH be unhappy with what they will be required to
provide.)

Step 2: (minimum - if you are interested in what MAY happen to COBOL in the
next few years)
 Download a copy of the draft Standard - and if nothing else review the two
appendices:
    - D.1 Substantive changes potentially affecting existing programs
    - D.2 Substantive changes not affecting existing programs

the first section will tell you about changes that MIGHT "change behavior"
in your existing programs; the second section will tell you (at a HIGH
level) what the major enhancements in this revision are.

Step 3: (if the last step "got you interested at all")
 Look at the section
    - Concepts

This section "describes" (in as non-technical as possible - which is still
pretty technical - way) many of the old and new features included in this
revision of COBOL.  Some (not as many as some would want) examples are even
included.

Step 4: (If you are a "do-er" and not someone who thinks that someone else
will make YOUR life easy/better)
  REVIEW the document in as much or as little detail as you want.
  Formulate your "comments" and send them to your national body (not to me,
not to J4, not to any electronic newsgroup or distribution list, but to your
national Standards body) and do this as FAR before the end of April 2001 as
possible.

REAL COMMENTS from REAL reviewers DO make a difference - and they DO get
looked at in detail (or at least in as much detail as you provide "us").

   ***

Some comments and suggestions on what *I* think will be "good and useful"
comments.

A) This document is pretty much at the "final" stage of development.  It is
HIGHLY unlikely that new features or enhancements to existing features will
be added at this time (unless "you" can justify that it would be worth
waiting another 2-5 years to get ANY revision of the '85/'89/'92 Standard
out.)

PLEASE do not use this review period to make suggestions of "nice to have"
additions for THIS revision of the Standard.  If there is something that you
just MUST tell people to think about adding, I strongly suggest that you
CLEARLY document this as an idea for a (possibly the next) revision of
COBOL.  Better yet, create a separate document with these "ideas" and send
them to the chair of the J4 COBOL committee marked "candidates for a future
revision" and include as much or as little detail as you think appropriate.
He can be reached at:

  doncobol <at> mediaone.net

B) It really is useful to say that you think that the whole document is
"swell" and you wouldn't change a thing (or at least wouldn't change a thing
if that means a "delay" in getting the Standard approved and out).  You can
even add "minor" editorial issues, suggestions, to such a comment.  However,
please do NOT assume that everyone in the world thinks that this is a great
idea (or even a worthwhile revision).  Therefore, it is important to hear
from people who think it is - unless you fall into the other category, see
below.

C) If you think that this revision should NOT be approved and published as
an ISO Standard, this too is useful information to convey.  However, it is
important that you ALSO tell why you think this.  Don't just be general and
say that "COBOL is dead" or something similar, but give specific reasons why
you think that the "programming world" will be a BETTER place (even for
COBOL programmers) if this revision is NOT adopted as an International
Standard.  (FYI - if you have read this far, this is the category that I fal
l in - but I won't go into details on that in this note. I will in future
input.)

D) ALL editorial notes are useful, but be aware that the ISO "drafting
rules" are specific and some things that are done in this document MUST be
done this way.  However, it is particularly useful to hear about additional
index entries that would be helpful (and where they should point to) or
cross-references and index entries that are pointing to the wrong place.
Similarly, if you find sentences or sections that seem to have been "messed
up" in editing (and don't make any sense), this too may be useful
information.  It really does help if you tell what the correction is and NOT
just point out what the problem is.  (For non-native English speakers this
may be difficult - but often if something doesn't make sense to you, it is
more important to get your editorial comments identifying problems than it
is to get comments who can "guess" at what was intended.)

E) PLEASE tell "us" about any technical errors that you find.  Not so much
things that are "fuzzy" but things where two (or more) parts of the Standard
conflict with each other - or where one part assumes something that another
says cannot happen. Similarly, parts of the draft that are "impossible" to
implement or otherwise technically "wrong". Again, the more specific you can
be (and the more you can provide "corrections") the more likely such
comments are to be "accepted" and acted upon.

F) If you do find "fuzzy" or unclear sentences (or sections), don't just say
that they were unclear but give SPECIFIC suggestions on how they should be
re-worded.  (Make certain that you clearly state which part of the draft -
page, section, and paragraph - you are talking about.  This is really true
for ALL comments that you submit).

G) If you think that there is something SO awful or so seriously flawed that
you think that it should be REMOVED from the draft Standard, this has a
"little" better chance of happening than adding something new.  HOWEVER,
almost everything in this document has been fought over for over half a
decade (some for close to a decade now) - so getting it removed would
require some PRETTY STRONG evidence of a critical problem (not just a
preference - or the way that you or your operating environment works today).

  ***

A special note about "spreading the word" - as well as spreading the
document.

PLEASE feel free to forward this document to as many people as you think
MIGHT be interested and willing to do ANY work on reviewing (and commenting)
on this document. You should, however, be aware that page ii of this
document states,

"This ISO document is a draft International Standard and is
copyright-protected by ISO. Except as permitted under the applicable laws of
the user's country, neither this ISO draft nor any extract from it may be
reproduced, stored in a retrieval system or transmitted in any form or by
any means, electronic, photocopying, recording or otherwise, without prior
written permission being secured. ..."

*HOWEVER* page xx states,

"Any organization interested in reproducing the COBOL standard and
specifications in whole or in part, using ideas from this document as the
basis for an instruction manual or for any other purpose, is free to do so.
..."

If you work in a "large" and/or "legalistic" environment, I suggest that you
contact *YOUR* personal legal authorities and/or advisors for an
interpretation on how these two statements (and their surrounding text)
impact you and your distribution of the document itself.

   ***

Happy reviewing - and please feel free to send me personal or public
questions if you need help in understanding what YOU can do and why I am
asking for you to do so.

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