| William M. Klein 2008-03-11, 6:56 pm |
| 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 ported 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@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 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/ =-
>
|