>Please define "widespread use." COBOL is similar to
>FoxPro / xBASE in that a lot of applications are
>still running, and being maintained to an extent,
>but almost no new apps are being developed in COBOL.
>With some exceptions, Y2K was the last gasp as far
>as being able to make a living writing COBOL.

"Widespread" in that there are literally billions of lines of COBOL still running on mainframes, pushing around the bulk of the data in the world, it works well on the web, and new apps are being developed -- mostly for mainframes. OTOH, for software developers like ourselves there isn't much of a market. Run time licensing can be significant, the footprint is noticable, the GUI sucks, etc. etc.

>You and Craig mention COBOL standards, meaning
>ANSI. They were not quite the panacea one might
>think. For starters there were multiple standards,
>and a new standard did not necessarily replace
>the one before. Some shops were sort of like
>"We're ANSI 85, except we ignore this part of
>it and still comply with ANSI 74." (There was
>even an allegedly object-oriented COBOL standard
>a few years ago, which is a mind bending concept).
>One of my colleagues back then remarked, "That's
>the great thing about standards -- there's so
>many of them!" Laughing Out Loud

Well, if you comply with part of ANSI 85, but stick to 74 for other items, then you really only comply with part of 85 (which is a pretty good standard). FWIW, about two years ago I dragged out a BOM/MRP system written to ANSI 74, made a few minor changes mainly to the environment data divisions, and had the application up an running on AIX in just a couple of days. This is 20 year old code still working today! Too bad the screens remind me of the Titanic sitting at the bottom of the Atlantic.

>Finally, the ANSI COBOL standards were not as
>neutral or community-based as portrayed here.
>They were not exactly controlled by IBM but
>not much got in that wasn't to IBM's liking.
>Similar to Microsoft today.

IBM has significant input but not a monopoly and they could never pull the plug on, or significantly change the direction of COBOL. Microsoft does what Microsoft wants and you are at their mercy -- as has always been painfully obvious. If you don't like life like that then code in C, C++, Java, or (good grief) COBOL. They are what I would call "standard" languages, a language with widely accepted standards not dictated by any one corporation. They usually aren't the latest and greatest, not the most productive, not always the way to go for cross platform compatibility (e.g. C and C++) but they do offer stability of a sorts.

Anyway, at this point in my application development, I'm looking forward to something that will be productive to program in, runs under as many Operating Systems as possible, and hopefully will be around for another ten or fifteen years. Python probably fills the bill on the first two counts and I am taking a gamble on the third point. If Python doesn't pan out, well there's Java, or what the hell code in C++ and forget the world exists. Either way around, I'm pretty sure VFP will still be working for me six or seven years from today so I have two or three years before I have to start taking concrete steps.

As I always say, JMHO,

Scott