Re: Bill Klein on proposed cobol standards

First, I have been an active "observer" of the COBOL Standardization process
from "around" the time of the '85 Standard.  During that time I have worked 
for
a compiler vendor (Micro Focus) and represented them on J4 (previously X3J4)
 and
CCC.  I have also been involved with the IBM mainframe user groups (the defu
nct
GUIDE and the current SHARE).  Currently, although I am not a Micro Focus
employee, I am listed as one of their alternates - however, most of my curre
nt
"involvement" is independent from MF or SHARE.

So much for introduction ...

***

My guess is that you are not really asking about the CURRENT Standards work 
(to
develop the next revision - "hoped" for in 2011 or 2012).  What you are prob
ably
asking about is all the "new" stuff in the '02 Standard.  From the way you a
sk
your question, my best guess is that you come from a mainframe (probably IBM
mainframe) COBOL environment.

The reality (as I see it) is that the world of COBOL usage began to "diverge
"
with Unix and then DOS->Windows in the late 80's.  In the '90s when there wa
s a
HOPE to produce a '97 Standard (well before Y2K), there was a strong push to
 add
to major things to the COBOL Standard

- "C-ification" which would allow COBOL to play in a world where most new
API's assumed C-like facilities (pointers, functions, etc)
- OO (There was a "COBOL Object Oriented Task Group" that began in the early
'90s and which SORT-OF resulted in the OO specification in the '02 Standard)

For a number of reasons (not the least of which was that there was no machin
e
readable easily manipulated version of the '85 Standard), what was hoped to 
be
delivered in '97 turned out to be a (IMHO) bloated COBOL Standard in '02 (wi
th
OO, among other things already implemented in incompatible ways by several
vendors).

In today's world, I see COBOL used in 3 ways:

1) By (primarily IBM) mainframe shops both in maintenance AND new developmen
t.
Used in such environments for both "batch" processing and as the back-end to
online applications.

2) In Unix/Linux (and a lesser extent Windows) environments for entire
applications that are ported off of mainframe - but retained in COBOL.

3) (Quite uncommon, but it still does exist) to create Windows (or Unix/Linu
x)
front-end and backend workstation applications. (Some of these were original
ly
written as long ago as DOS - and have been maintained and enhanced since the
n).

***

Generally, the '85 Standard worked "OK" for the first category (and still do
es).
However, there has been SOME user and implementer demand since the early '90
s to
also be able to meet the 2nd two categories. Such demand seems to be decreas
ing.

This has been a major "simplification" and reflects my views only - but trie
s to
answer your original question.  If it doesn't, please help me to understand
exactly what you are asking and from what environment you are asking it.
--
Bill Klein
wmklein <at> ix.netcom.com
"SeaSideSam" <SeaSideSam@TheBeach> wrote in message
 news:da195$47d6eb12$6214906e$15507@ALLTE
L.NET...
> i've been studying (reading actually) the proposed cobol standards.  and i
've
> noticed that you seem to be involved in some capacity (observer to
> implementor).  is there a simple explaination as to why there is so much
> interest in making COBOL into ....  ?  COBOL, like every other invention o
f
> mankind, needs the occasional make-over.  but this seems a bit much.  ther
e
> might be good reason, a valid destination, but i don't see it.  maybe you 
can
> explain.
>
> tia.
>
> it's like taking a mack truck and turning it into a dodge 3500 dually.  ye
s,
> it's still a truck, still diesel powered, and still carries a load.  but w
hat
> you end up with is really something completely different.
>
>
> --------------=  Posted using GrabIt  =----------------
> ------=  Binary Usenet downloading made easy =---------
> -=  Get GrabIt for free from http://www.shemes.com/  =-
>