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
defunct
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
current
"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
probably
asking about is all the "new" stuff in the '02 Standard. From the way you
ask
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
was 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
machine
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
(with
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
development.
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 ****ted off of mainframe - but retained in COBOL.
3) (Quite uncommon, but it still does exist) to create Windows (or
Unix/Linux)
front-end and backend workstation applications. (Some of these were
originally
written as long ago as DOS - and have been maintained and enhanced since
then).
***
Generally, the '85 Standard worked "OK" for the first category (and still
does).
However, there has been SOME user and implementer demand since the early
'90s to
also be able to meet the 2nd two categories. Such demand seems to be
decreasing.
This has been a major "simplification" and reflects my views only - but
tries 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@[EMAIL PROTECTED]
> wrote in message
news:da195$47d6eb12$6214906e$15507@[EMAIL PROTECTED]
> 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
of
> mankind, needs the occasional make-over. but this seems a bit much.
there
> 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.
yes,
> it's still a truck, still diesel powered, and still carries a load. but
what
> 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/
=-
>
|
