Slashdot Mirror
Modernizing the Common Language - COBOL
Frumious Wombat writes "Over at the Register Developers section, they are quoting the head of research for Ovum Consulting on the continuing dominance of COBOL in certain business applications. The antique language accounted for 75% of all business transactions last year, and some 90% of financial transactions. For all the time spent arguing the merits of Ruby vs. C#, should the community spend more time building tools to make COBOL livable? The article goes into what it terms 'legacy modernization', and lays out some details on how to go about it. From the article: 'The first stage in the legacy modernization process is to understand the business value embodied within legacy systems. This means that developers must give business domain experts (business analysts) access to the legacy, using tools that help them find their way around it at the business level. Some awareness of, say, COBOL and of the legacy architectures will be helpful but we aren't talking about programmers rooting around in code - modern tools can automate much of this analysis for staff working at a higher level.'"
"Hannibal's plans never work right. They just work." Amy/A-Team
Modernize? Pah.
Why not just rewrite it in PHP. Another 30 years of guaranteed fat support contracts. Always think of your potential pay-packet.
No.. it had it's time, please let it die.
Seriously, MS has had no real reason to do a secure OS. In fact, the opposite is true. It is the add-ons that make money for everybody. Of course, with apple having been secured and linux up and coming, MS is finally under pressure to do the right thing.
One of my friends who ends up porting and bridging Cobol systems was quick to inform me, "COBOL is OO, look, see, print line is extending space".
+++ UGUCAUCGUAUUUCU
ADA is still used by some goverment defense agencies also. It would be nice if there was a nice open source COBOL IDE. Funny thing is that all these new languages, fix issues that are not huge issues to most to begin with. I'm sure if someone made it easy to call web services from COBOL and made it possible to do OOP in COBOL it would be more accepted, but because it is a very primitive language people hate it.
Only 'flamers' flame!
Does slashdot hate my posts?
Remember: columns 1-6 are sequence number, column 7 is indicator.
:-)
Go forth an set thy tabstop to 8 and you should be able to make your hello.cob compile!
Because, it makes sense.
You don't have to develop corporate variable naming standards, coding standards, and all that, because the language makes it happen automatically.
You can take a fresh wet behind the ears kid, give him the code, and he can figure out what's going on without any significant trouble, because it happens in order, there is none of this fancy renaming variables on the fly and obfuscating code with magic numbers stuff that is all the rage in C++, Java, and other "modern" languages.
You want to add 2 and 2? Great, you get 4, which is what the accountants want. You can't program 2+2 to equal 27 like you can in C++. One operation does one thing, does it well and accurately, and moves on.
Business only has one real question: "How much money did I make last year?" COBOL provides all the tools to answer it.
That is why COBOL lives, and always will.
and I can't wait for them to update FORTRAN. Oh, for the days of punch cards!
"You'll get nothing, and you'll like it!"
From TFA: "So, perhaps the real bottom line is that legacy reclamation isnt a second-class project for tired developers. It is an important part of your IT process and needs access to your best, brightest and most flexible brains."
If only such decisions could be realized in today's business setting. Unfortunately, updating/migrating legacy systems (even mission-critical ones!) seems to be the assigned task for interns, new hires fresh out of university, and contract programmers in India.
Insisting on "correct" English is like saying that there is only one, definitive recipe for chili.
Every person I've met with writing talent throws lots of stuff away. They do it without a second thought, and the next attempt is almost always better. Why should writing software be any different? If the legacy is so bad as to be entirely undocumented and filled with back doors, work-arounds and pitfalls, what do you lose by rewriting? It's not like editing the crap code is going to be any faster or less error-prone.
In fact, there's many benefits to rewriting. It allows for proper documentation to be created (design diagrams, use cases, requirements documents) if it was missing. It allows for new technologies to be considered, and to plan for another 30 years of operation. If the software was created using a robust process, the design diagrams, use cases and requirements documents are already written. That's the hard part; any coder worth his salt should be able to exactly duplicate the application from those artifacts.
I don't think the risk is as bad as business types claim it to be. Is it really any more of a risk to "Rip and Replace" when it's at least as likely that either the ancient hardware that the application runs on fails without replacements being available, or that the one person in the entire company who actually knows all the stuff that should be written down in the non-existent documentation retires, and there's no replacement available? The article mentions in 2 of the 3 legacy reclamation techniques that a domain expert would be required. The fact that many of the domain experts are going to be or have already retired should be additional incentive to do the "Rip and Replace" while they're still available.
mandelbr0t
"Please describe the scientific nature of the 'whammy'" - Agent Scully
the continuing dominance of COBOL in certain business applications. The antique language accounted for 75% of all business transactions last year, and some 90% of financial transactions.
That sounds less like just plain COBOL, and more like a cabal.
The theory of relativity doesn't work right in Arkansas.
Help stamp out iliturcy.
Comment removed based on user account deletion
Does any school actually teach this computer language? Have these "legacy" programs been running flawlessly for all these years? Are the programmers from the 1950's still around?
One, these figures result from the simple fact that COBOL was pretty much the only high-level language around at those pre-historic times many of the major applications were written. And banks are very, very conservative environments where something that works will not be thrown away for something that might have bugs, even if it's 10x as fast, easy to maintain or whatever. It has to work and that's priority #1, #2 and #3.
Two, the reason COBOL is so widespread in financial institutions has nothing to do with business sense and everything with business mind. It is "readable" to a business dude with zero computing experience. Something like "ADD PROFITMARGIN TO PRICE" just makes these people feel more at easy than "$price+=$p_margin".
Assorted stuff I do sometimes: Lemuria.org
Just merge C, Ruby, & COBOL syntax into one compiler.
Now coders can start migrating away from Cobol without the hassle of rewriting entire programs. They can do it one line at a time, as they get to it.
Now if we could just merge Java, & Perl in there you'd really have something.
Shop smart, Shop S-Mart.
This simply underlines the fact that there's a huge workload of easy, routine transactions that need to be done.
In terms of total complexity, the financial world is probably something like Excel 20%, C# 15%, Java 30%, C++ 30%, other 5%.
But in terms of transactions, I can well believe it's COBOL 70%, REXX/VB/4GLs 25%, other 5%.
Modelling a CDO *is* hard, and you don't do it in COBOL. Creating a visual system to monitor liquidity *is* hard and you don't do it in COBOL. 'Transactions' pure and simple are not hard... you can do them in COBOL... they're easy to maintain because changes are of the form 'deduct 5% if broker_country_of_incorporation = finland'... and they're also a darn silly way to measure the relevance of a language.
Whence? Hence. Whither? Thither.
...hear my prayer!
But, does this mean that the "community" should help? Why should *I* build such tools, why should *you*? That's the problem of the financial institutes, and they are willing to pay large sums to get their code maintained and modernized in COBOL. And if they want to have a nice development tool, so they have to pay for it (probably indirect by paying a software development enterprise, which creates and then uses such a tool).
Once you guys get jobs in the Real World, you will realize that businesses don't care about technology, they care about solutions.
No business person in their right mind would rewrite all their COBOL code into C or Java just for the sake of modernization. That would be foolish and stupid, and they would deserve to be fired from their jobs. Everything works, why change it. Financial institutions that have their entire livelihood based on these COBOL programs would rather upgrade their hardware and make THAT modern, but keep their legacy code. They already went through a multi-billion dollar fixing for the Y2K industry, that's more than enough for them. The next problem is either 2038 or 2050, when the Y2K issue is revisited because of how most companies implemented their "fix" (any date > 50 would be considered in the 21st century).
I was working at a bank during late 90s and during a building-wide Y2K meeting, one of the project managers was explaining to us how they implemented the solution. Someone in the crowd asked "Won't we go through this problem again in 2050?" He answered "Yes, but I'll be dead then, so I don't care."
That is how business people think... they care about solutions, they don't care about technology. Don't waste your time navel-gazing and trying to figure out brilliant ways of modernization COBOL, because no one who uses it cares. Keep your great ideas for the new ideas where the barrier to implementing new solutions and new technology is much lower.
The problem I had with COBOL, PL/1, Pascal and Modula 2 were they were wordy.
A lot of typing to perform simple operations. This is why I like C, minimal typing for great power.
More or less works for Java and later languages, too.
A feeling of having made the same mistake before: Deja Foobar
Went through scholar.google.com and found a 1997 abstract that claims that OO Cobol has been in developement since 1989. So it has been tried for a long time. But Cobol coders dont exactly take to OO like fish to water.
sed -e 's/Chuck Norris/Rajnikant/g' joke > fact
When asked about how to improve Pittsburgh, the famous architect had an immediate reply:
"Abandon it."
Cross out 'Pittsburgh', replace with 'COBOL', you get the idea.
I am 56 years old and would love to learn COBOL, if it means that I can get a better paying job.
Obviously, COBOL works. In fact, if statistics are to be believed, then it is perhaps the most successful of all computer programming languages.
Why replace what works? In fact, why do employers always want to replace me with someone younger and cheaper and not necessarily more gifted?
Never trust anyone under 50 should be my sig line.
Help end the use of Sigs. Tomorrow
Considering the vast majority of the community hates COBOL with a passion, I think it would be easier to get together a group of people who want to promote (insert your favorite band's name here) latest album.
The reason there is so much legacy code about is because that code has been around for some years, is proven and is bug free.
The slashdot article assumes that because of this the code may benefit from change. In fact the exact opposite is the case. Change introduces bugs and costs money, so I cannot see this happening.
The antique language accounted for 75% of all business transactions last year, and some 90% of financial transactions. For all the time spent arguing the merits of Ruby vs. C#, should the community spend more time building tools to make COBOL livable? The article goes into what it terms 'legacy modernization', and lays out some details on how to go about it.
I mean, it's only big (huge!) corporations running big back-ends that use COBOL, why should "the community" bother much with that? I doubt it's anyone's itch to scratch. Customers want to run COBOL because the code has had decades of real-world production use, not because of COBOLs merits. If the same people still ran assembler code, I'd trust that too. Doesn't mean I'd like to give up on modern languages because of it. If I heard the words "legacy modernization", I'd think "don't break what works". Doesn't mean big new developments are made in COBOL, they interface it.
I'm almost convinced that COBOL will be running on systems a hundred years from now. Any Turing complete language could produce working code to solve anything (or well, as much as any other Turing complete one, anyway). Clearly there's some such code in COBOL, which it makes no sense to reimplement in another language just for the sake of reimplementing it. But I don't see the benefit of trying to revive COBOL development, there are now much better tools for the job. How long has it been since the term "Completely Obsolete Business Oriented Language" was coined? It's dead, Jim. The only tools needed are those to ease its passing.
Live today, because you never know what tomorrow brings
There are options out there... even without dropping a bunch of money...
Manufacturers:
http://www.openmfg.com/
ERP/CRM:
http://www.compiere.org/
Open source ERP/VE business engine in PHP/Postgresql/Apache and Mozilla's XULRunner client.
http://www.venture.kdsi.net/
90% of transactions happen through COBOL? Is this supposed to make me want to programin COBOL?
Sorry friends, but I have to work on code that matches my passion. Otherwise I would not be able to swing my legs out of bed in the morning and live my life with joy. Some people may be making a living with COBOL but none of the cool kids (myself included) will touch it.
Sounds like a job for Parrot!
Note: I'm kidding... sort of.
Hire a Linux system administrator, systems engineer,
I've got certification in COBOL. I remember clearly learning the language with punchcards. I liked it that way. COBOL should stay the way it is. We should return to the good old days of punchcards.
The big advantage COBOL has is that the language is serious about data storage. The language knows about structured files, databases, indices, and formatted fields. COBOL was the first language to have data structures.
Look at what a mess it is to talk to a database from Perl, Python, Java, or C/C++. There's fussy glue code required, and the language doesn't help you make sure that field XYZ in the database comes out as field XYZ in the program. In COBOL, it's straightforward. The language knows about databases. There's even a good interface to MySQL.
It also has some formatting capabilities that HTML should have had. You can write CREDIT-CARD-NUMBER PICTURE 9999-9999-9999-9999. In some systems, that will eventually result in an input field on a green screen that will only accept four fields of all numbers with all digits filled in and will display a blank form field accordingly. HTML FORM fields should have worked that way.
There are some real advantages to a language where components outside the individual programs can see, check, and use the data declarations.
The last three items make COBOL memory- and CPU-efficient. The programmer is limited in his options, but these restrictions also gracefully limit coding complexity. Portability is simplified with this restricted feature set.
A side-effect: COBOL is an ideal language for WWW applications because of the above restrictions/features. COBOL is the original WYSIWYG language.
Chased a missing period, or dealt with an ALTER statement?
Now, the ALTER statement, at least, is probably history. I'm not so sure about the periods.
One such company, Envyr Corporation (makers of iCobol), builds a solid windows-based IDE for COBOL. Their compiler supports many different architectures - AIX on RS/6000, DG/UX on AViiON (though, newer versions aren't supported on this platform), HP-UX on HP Series PA-RISC 1.1, Intel RedHat (above kernel 2.2 for newer releases), SCO (yeah, yeah, I know). They also support the full line of Windows OSes, though older versions like 98, NT and ME only have basic testing performed on them.
They provide tools for transitioning from older Data General COBOL to newer OSes (Windows, RedHat).
Interesting thing also, is they provide a cgi platform for COBOL.
They also provide various APIs for C to interact with the COBOL program you have, services for code migration, etc etc.
The company is run by several ex-Data General employees, and they really know their stuff.
Disclaimer: I do not work for Envyr Corp, but I have family that does.
Show me some real world data on TCO including lifetime maintenence that terse programs, which saved a few minutes of typing for the programmer, are better then wordy programms whihc save years for the non original authrs that have to maintain
this less typing thing is one of the stupidest memes in the computer industry
Business only has one real question: "How much money did I make last year?" COBOL provides all the tools to answer it.
Well, if you use COBOL to code your web frontends, graphics, analytics, etc., the answer to that question will be near zero.
In order to make money these days, you need to do more than can humanly be done in COBOL.
there is none of this fancy renaming variables on the fly and obfuscating code with magic numbers stuff that is all the rage in C++, Java, and other "modern" languages.
C++ and Java are not "modern" languages; their designs are barely more modern than COBOL, actually.
If the programmers and/or managers still think COBOL is useful, why not let them deploy its applications. If COBOL has survived it is only because it is relevant, or make easy to understand its legacy systems. It is well standardized by several organizations and have several commercial and free implementations. Compare for instance Java, which IS NOT standardized yet, have a few (SUN alone is the standard) implementation, and is a moving target!
If I would choose a language to port COBOL applications, I would prefer Common Lisp. That's because I like it. It gives me control and power. There are many things impossible to do in Java or C++ (and COBOL too) that's easy in CL (real macros anyone?).
Of course, for business applications, or better saying, for the junior programmers that are able to write COBOL or Java code for finnancial applications, Common Lisp is a nightmare with its complex concepts. For a seasoned programmer, there are, along with CL (Common Lisp), a handful of other interesting languages such as Ruby, Tcl, Python, and others.
But remember, there are tricks in COBOL that no other language (except CL, of course, that may implement the syntax you need) which features a MOVE (with type conversion according its PICTUREs), MOVE CORRESPONDING, a precision "money arithmetic", several verbs like INSPECT, STRING, etc. People get used to work with those features! That's why COBOL still lives and will live for much more time than you Java-only programmers (Java morons) expect.
In Brazil there's a saying "don't change a team that's winning".
BTW, I'm NOT a COBOL programmer, but I'm a proud implementor of TinyCOBOL (http://tinycobol.org/ or http://tiny-cobol.sourceforge.net/), a free (GPL, libraries LGPL) COBOL compiler that peaked 4,000 downloads/month. I prefer to write my code in Tcl, Common Lisp (including CLOS, its object system), Prolog, C (not C++, which is ugly), yacc/lex/ox (compiler tools), TeX, Postscript, Smalltalk, Forht (I've implemented a derivative of it called "Filia" in the early 70's), and othe less known animals...
Rildo Pragana -- "Adventures in Linux Programming" http://www.pragana.net/
Comment removed based on user account deletion
If a code has to be re-written (or in this case the own language COBOL) it is time
to switch it by another and modern language.
Everything is evolution, except my score that keeps on 0 indefinitely:)
Comment removed based on user account deletion
I worked with a company that had most of their IT systems on an old mainframe written in COBOL and assembler. We had to migrate a few programs to use DB2 (relational) database instead of IMS (an old hierarchial database). This proved to be a nightmare due to lack of tools to analyze COBOL source code. We had to write REXX scripts to parse the code and automate some of the process. In another project, a variable had to be expanded (in terms of lenght), and another nightmare followed. More rexx to track where this veriable goes, what it is used for, what files it gets written to .. well this part involved parsing JCL files as well using rexx!
Yes, we need better (mainframe based) tools to make this language livable with.
seems it's already quite 'livable', considering its stated dominance in some applications.
Blasphemy. Rewriting the sacred text of the colonies. Where's Cmdr Adama?
Some drink at the fountain of knowledge. Others just gargle.
geez, it's not riddled with bugs, has a stable development environment, stable kit of tools.
it just works.
unlike what, ALL the rest?
I wouldn't mind taking a peak at COBOL syntax (just another syntax), but I don't want to get steeped in the COBOL culture. How to use language features to isolate transactions, what are the types and advantages of batch job approaches. That would take a long time to learn, and could send a career in a COBOL direction.
Censorship is telling a man he can't have a steak just because a baby can't chew it. --Mark Twain
Sorry, but I have to rant: Whoever wrote this has no idea what they're talking about.
COBOL is the glue language in a stack of application components sold by IBM including CICS (or ISPF), VSAM, DB2, etc. These are quite modern and up-to-date, and run on the mainframes that make the world go around by providing reliability and uptime at load levels beyond the wildest dreams of PC and Linux users. Sure, anyone could learn COBOL basics in a day or two, but you're not going to learn and certainly not going to "modernize" a COBOL program running against a DB2 database. COBOL is a glue language that glues together high-performance relational database access, high-performance presentation-layer management (CICS makes Windows API programming look simple!), etc to process umpty transactions per second, where umpty is a number beyond the reach of most Linux boxes. You're never going to "modernize" this stuff because it's the only thing around that can do what it does at that throughput level. The COBOL part is just a driver among the different components. Even the business logic has been factored out into stored procedures now.
There is no problem bolting on web access to databases and data warehouses, or stuff like that, but whoever wrote that (imagine that, a consulting group who will come in and modernize everything for you!) has absolutely no idea what COBOL applications are or do. You are most definitely not going to port legacy applications to new platforms that use CICS or ISPF for their presentation layer! Get a clue. And what platform are you going to port your COBOL program to? The mainframe is already the highest end platform of all time - there's nothing with more throughput - I doubt a company would take the notion of porting to MySQL on an Intel box very seriously. The bottom line is people use the IBM application stack because it works, at a performance level where nothing else works.
Sure, it would be fantastic to have an open source COBOL compiler with a MySQL precompiler so people could learn the language (ever tried to parse COBOL!?). And a Mono COBOL compiler would be fantastic. But no one is going to port their mission-critical business applications from a mainframe to a virtual machine runtime environment. You might use C# or Python to create new apps to access the data in new ways, offline, but you're not going to port mission-critical stuff.
Who are the monkeys above suggesting they re-write it in a dynamic language like perl/php/ruby on shit? I think you'd be hard pressed to find any critical back-end business logic not done in static language like java, c, c++, c#. It would be moronic to write that kind of code in a loosey goosey language.
Yeah, I guess you must be a COBOL programmer, since you seem to like TYPING IN ALL CAPS.
Anyway, the appropriate acronymical expansion of COBOL is 'Confused Oriental Bean-cOunting Langauge.'
Oh, BTW, how's the fingers? Stubs yet?
My blog
there is none of this fancy renaming variables on the fly and obfuscating code with magic numbers stuff that is all the rage in C++, Java,
WTF??? This guy does not know the first thing about C++ or Java.
The company I work for have a rather large legacy web app (600mb of code) running on asp and mysql.
Unfortunately at some point we will have to rewrite it in PHP. Before I got to know my way round the system I thought this was a great idea as I am a pretty good PHP programmer and prefer it to ASP. Now I have realised what a huge and difficult job this is going to be (think in man years rather than hours) I am not so keen. Especially as I will probably be entitled to a profit share by the time we do it and obviously a huge internal job like that will not generate as much income for the business.
I dont read
RTFA! This is just an ad for Micro Focus.
Media that can be recorded and distributed can be recorded and distributed.
-kfg
$ SET FREE
77, 95, 2003
(I skipped the 80s too.)
Like all the legacy languages it acquired all the new fad constructs. Still pretty conscise for formulas and array operations.
That book is actually a pretty good intro to C++. It's how I got my start when I migrated from C about 10 years or so ago.
Best Slashdot Co
Of the ancient three: COBOL, FORTRAN, LISP - FORTRAN has many legacy applications too. Its not uncommon to see some dusty FORTRAN-77 deck in an oil company or national lab. Most compiler switch back to that standard.
If the software was created using a robust process, the design diagrams, use cases and requirements documents are already written. That's the hard part; any coder worth his salt should be able to exactly duplicate the application from those artifacts.
You make it sound so easy! How many times have you actually done it?
I ask this because I have done it, several times. Each time, I knew exactly the logic of the processes, knew all the applicable algorithms, and had all the documentation and flow charts. Writing from scratch a program to replace the COBOL code was a non-trivial exercise, involving several months of coding and testing. Those were, in retrospect, rather small programs (10-25K lines) too. The only reason I did it in the first place was that we needed to have a better front-end data entry, and there were some issues with batch output file sizes - this was in the early '80's.
Yes, it sound really easy to say "just rewrite", but the reality is that even in optimal circumstances, it isn't always simple to transfer between languages, and particularly not when you start getting into major applications. "Legacy" is not necessarily a dirty word.
Even back in the early '80's, it was an axiom that COBOL was "dying," and would soon be replaced. Amazingly enough, it hasn't happened, but many of the "more powerful, better" languages that were supposed to supplant it are pretty much forgotten or not commonly used. This leads up to the question of exactly which language do you plan on rewriting in? You, yourself, have postulated a thirty year lifespan. Which of today's "hot" and "powerful" languages do you think is going to last that long? C? C++? D? Pascal? Java? Python? Perl? All of them have had (or are having)their day as the new "best" programming language. Some of them have also fallen by the wayside, or are having people start to leave them for the new "next best thing." Is someone in thirty years going to know how to program in one of them, or learn the language easily?
I wouldn't take too many bets on that. Maybe I'm wrong, but I would be willing to take some serious money on COBOL still being around. It does what it's supposed to do, it's easy to learn, it's portable, and it works. That's pretty much all we can ask of any programming language. Which is why this language has lasted as long as it has, while many of its "replacements" have gone away, whether any of us like it or not.
To paraphrase what Charlton says about his rifle.
He must be an IBM consultant, he knows the dark secret!
I patented screwing your mom. But it got revoked for "prior art."
There Is No COBOL.
Yep, and when you realize that you have sabotaged your career by tying it to dinosaur technology you can't blame anyone but yourself. COBOL was great for it's time -- of that I have no doubt. But, the reason the only guys you can get to work on an old OS/390 system isn't necessarily because they like OS/390, but they never changed with the times and diversified and that's all they are qualified to do. I don't know anyone who even knows anyone, who is written NEW COBOL code. So, maybe your thing is supporting someones 30 year old COBOL system -- a job fit for someone waiting to retire from the age of 25 forward.
Dude, like, everyone knows that 2 + 2 = 22:
<shameless plug>
In our research group e.g., we're evaluating aspect-orientation (AOP) as a means to both reverse-engineer (understand) and re-engineer (modify) legacy software written in Cobol or C. To this end, we've designed and implemented an aspect language called Cobble (http://faramir.ugent.be/~kdschutt/cobble/) and applied it on some typical legacy problems like Y2K, transition to Euro, encapsulation of web services,
</shameless plug>
Now, the biggest problems we encountered for Cobol (contrast this e.g. with the Java world) were:
Eventually, we had to implement our tools from scratch, tied to a subset of one particular Cobol dialect. This severely reduced the time for actual research. So, Cobol is not so simple as it may seem at first sight and this is aggravated by the limited (compared to Java, C#,
I used to think that way 6 years ago. Now I know that's dead wrong. In literature, you lay out your feelings / your ideas. They develop over time, and with each re-write become clearer to you and on the paper. In software, your ideas seldom matter. What matters are requirements that develop independently from you, and workarounds for various issues that have nothing to do with your creativity, and develop themselves just out of necessity. Software is not an expression of ideas, it's a machine, and should be treated as such.
Comment removed based on user account deletion
"The antique language accounted for 75% of all business transactions last year, and some 90% of financial transactions. "
.net, pythan, perl, etc. are all unproven
should be:
This mature language accounts for 75% of all business transactions last year, and some 90% of financial transactions.
It works well, and has compilers that have been improved for 25+ years.
It is sad when people want a language thats new and unproven over a mature language that works.
And for this type of enviroment Ruby,
The Kruger Dunning explains most post on
Just to add to the parent post: COBOL and RPG are both simple languages that happen to fit the domain of transaction oriented and batch processing for business applications. These apps typically don't require advanced data structures and OO techniques to reduce complexity or increase manageability of the system. Typically a business transaction follows a relatively sequential process of conditionals and setting status/adding/subtracting value/storing new info, lather, rinse and repeat. These languages include operations designed for this basic movement of data, in and out of the DB, between work areas, and decimal math operations. The additional functionality in other languages typically doesn't add much value in this arena.
Comment removed based on user account deletion
"should the community spend more time building tools to make COBOL livable?"
I thought that was the job of the pharmaceutical industry.
Oh please, god, no!!!
I started my professional programming career in 1999 by doing y2k conversion on an s/390. Millions of lines of COBOL. All my friends at college had the cool jobs of C++ GUI's and Java web apps. Even the professors laughed at me when I told them what I was doing. Do you know strange it is to work on code that was last updated 9 years before you were born.
In all seriousness...
I can understand why COBOL is still popular now. From my experience, most major companies made a big technology leap a long time ago, investing millions in massive mainframes to run the company. These systems are still held up and run by their aging staff. (I was 17, the next youngest programmer was 50+). These systems get so massive and complex, "modernizing" is just another word for rewriting.
I suppose 20 years down the road, we'll all be complaining about legacy java systems. 50 years down the road, legacy ruby systems.
How about a Perl module that snarfs COBOL sourcecode and spits out Perl source, which then is either eval()'ed against the COBOL formatted data, or just stored for later execution as a standalone script? How about a Perl6 module that compiles COBOL sourcecode to Perl bytecode? COBOL is mainly just printf(), with the remaining fraction doable in Perl anyway.
--
make install -not war
There is one aspect of COBOL that I have never seen bested by any language; the ability to slice and dice a record, move it around, copy it, redefine data types as needed, etc.
And as for maintaining, a properly written COBOL program has no equal in ease of understanding what the heck it is doing to what.
When Fascism comes to America, it will call itself Anti-Fascism, and tell you to give up your guns.
Unfortunately I am old enough to weigh in on this. The most productive COBOL programmers back in the day used secretaries who manually transcribed abbreviations and shortcuts into COBOL syntax, using memorized templates. The programmers themselves operated only with the abbreviations. This practice turned out to be a very significant productivity win.
Less typing is not a "stupid meme" at all, at least as it applies to COBOL. However, the arguments by C bigots that they have to type more in Java or whatever are, I'll agree, silly.
can't replace the existing 200 billion lines of code.
Sure you can. A 20 line Perl script would probably work just as well.
And you can't maintain 200 billion lines of COBOL, either.
But seriously, COBOL is so verbose that the 200 billion lines of COBOL could probably be replaced by 100 million lines of C++ or Java. And it would be more maintainable. COBOL exists to keep programmers employed; consider what it provides for the programmer:
MULTIPLY HOURL-WAGE-IN-CENTS TIMES HOURS-LOGGED-FOR-THIS-EMPLOYEE-ONLY-NOT-INCLUDING
ADD TEMPORARY-SALARY-FOR-THIS-WEEK TO ONE-TIME-BONUS-FOR-SALARIED-EMPLOYEES-NOT-RECEIVI
MOVE BY NAME TMP-EMPLOYEE-SALARY-CALCULATION-WORKSHEET-STRUCTU
But I jest, of course. The truth is, most businesses are so afraid of moving away from COBOL that they'd rather continue to shell out premium salaries than take the risk of a failed migration. Kind of like a lot of Windows users - they'd like to try Linux, but are afraid of change. Well, I suppose you get what you deserve.
The society for a thought-free internet welcomes you.
Add 1 to COBOL
Old, dead, languages with no job potential or revenue potential for tools means that we will expend no effort over it.
... but that doesn't mean that there won't be a need. It will happen, and for some companies they are just putting off the inevitable a little bit longer.
Corporations that are still on cobol are eventually just going to be screwed (if they wait too long). A 486 could handle the same problem, much faster nowadays, and cost less to run. Rewriting a million lines of cobol could be done in 50k lines of C# or Java. Maintenaince would be easier. Bugs would be fewer. Imagine all the dead code accumulated in that mess over 20 or 30 years.
I'm all for "don't spend money until you need to"
All they need to add is a "#AnotherLanguage" directive.
...
Example:
#AnotherLanguage: Ruby
#AnotherLanguage
Seriously, I see people moving Cobol programs from mid-range boxes to Windows Cobol on stock boxes with relatively low effort all the time in the insurance space. That usually works out pretty well, which says something about Cobol I guess.
...Chris has the good looks of Antonio Banderas and is hung like John Holmes
I thought the use of hung for people was bad form, so shouldn't it be: "Chris had the good looks of Antonio Banderas and was hanged like John Holmes."?
When our name is on the back of your car, we're behind you all the way!
In 25 years time the same class of articles dealing with legacy systems and languages will be written, except they will be about Java instead of COBOL.
In the course of every project, it will become necessary to shoot the scientists and begin production.
You have to keep your skills up to date with what's valuable, not with what's new.
Thanks to outsourcing, you can get five, maybe ten dollars an hour for pre-spec'd Ruby or C# these days. Every high school kid in China and India is learning them, so paying more then that is foolish since there is probably a free open source solution anyway.
I dunno about you, but that makes Ruby and C++ rather uninteresting skills to have. McDonalds will pay ten and hour for someone that speaks English (around here being legal makes you management).
COBOL on the other hand you can support your family with, for now.
- Adam L. Beberg - The Cosm Project - http://www.mithral.com/
I'm 54 and have been programming my daily bread in COBOL for the last 30 years. If you've got any experience in other languages COBOL shouldn't be too hard, just a pain in the butt.
:)
Knowing other languages doesn't hurt of course, I love playing around with LISP/Scheme, Smalltalk and have frittered away countless hours with Ruby, Python and even Forth.
Main thing is (as a later poster recognises) is that familiarity with the biz world (or application domain, is that still a valid buzzphrase?) is what also helps.
As to being replaced by a 21 year old it's unlikely since they think COBOL smells funny and their Java toting buddies will laugh at them. Of course they're usually wet behind the ears when it comes to a particular biz anyway and need some mentoring. But most are salvagable.
The author mixes the idea that the business process (how you do stuff in the business) is modernized if the architecture (the tools used for implementation) is modernized. So, if we use an SOA wrapper over a COBOL app we've modernized the business process. The business process is completely orthogonal to the language/platform being used. While tools like BEPL and SOA can enable flexible and modern practices, they don't guarantee that will be the fruit of your labor. A green screen app may represent an interface into the most modern, agile, and well thought out business process (i.e. how you do stuff for the business). An SOA may be an interface into the most 19th century, retrograde, stupid means of doing something business related (like sending e-mails to 3 different people to get approval to spend $10 on a new pencil sharpner).
There's no such thing as a bad or dead language. There are languages that are better or worse than others for certain tasks. I make my bread and butter doing web apps. I started in C++, moved to Java, and now I'm working with Ruby. I've used what I felt were the best tools for the job at hand. For graduate school I spent a lot of time with Lisp, because that was the best tool for the job. For all my IT brothers and sisters out there busting COBOL for a living, I say be proud!
Leave the gun, take the cannoli -- Clemenza, The Godfather
The problem with all of these modernization projects is not the language. It is the mass of old data, and the huge mass of business rules that are implemented by the old code. Reimplementing the business rules in new code, without interrupting the business, is just about impossible. Turns out the easy way is usually to just port the old Cobol code to the new environment.
The problem is not the language. The problem is the environment. Consider: A lot of that old Cobol code presently runs on Autocoder 790 systems, which are run by emulators on an OS 360 system, which is run by an emulator on a 390 series "mainframe", which is run by an emulator in the old Sun box that gathers dust in the corner of the old data center.
We really don't need a new language. What we need is something like a Cobol compiler, with an ISAM file-system emulation library, that outputs code for a well defined machine such as a java virtual machine. Then the resulting executables can run on whatever box happens to be handy next year.
This is either funny or insightful. Maybe both.
Well, at least COBOL has array bounds checking. Unlike C/C++.
With the parser features in perl 6 COBOL can be reimplemented in 20 lines of perl:)
-- To dream a dream is grand, but to live it is divine. -- Leto ][
The guy that said this from Ovum also said a lot more (HERE), cited on Microfocus' web site, the maker of Microfocus Cobol (yea, they are not biased....). Microfocus does make a good Cobol compiler BTW. That quote could be 10 years old or more and probably is. Most of finance moved on years ago and don't run a single line of Cobol anymore. NYC has a lot of mainframes displaced with blades and linux. IBM helped a lot of them do it. I know I threw all of my Cobol/MVS/other mainframe crap out years ago. I haven't even had an inquiry about that stuff for years.
I've never supported COBOL, but I've supported my share of legacy business logic written in 1960s era languages.
Once you get beyond the overhead of 100-200 lines of code shared by all COBOL programs (ENVIRONMENT DIVISION, etc.), some single lines of COBOL can perform some powerhouse tasks. It's not all "ADD SUBTOTAL AND TAXES GIVING TOTAL" type stuff.
Now, as to speed: remember that COBOL compilers have become pretty damned efficient over 40+ years. I have seen 1,000 line COBOL programs compile into 24K executables (that's K not M), all of it optimized native machine language. And since COBOL programs are by nature procedural, not too much dead code escapes notice and stays in. I have seen COBOL programs running on a 25 year old 8-bit processor (IBM S/38) rip through a million row table in less time than a modern server would take using Java code hooked up to PostgreSQL (with all its abstraction layers, etc.) - COBOL, done properly, is anything but slow.
Cobol supporters I have met and those online are unfamiliar with the rest of the computer industry. That is how they can spew out streams of statements patently untrue and hilariously ignorant. Oooo...structures! Oooo...business rules! Even two older languages (Fortran and Lisp) are much more advanced.
Cobol people would do best to not argue here in defense of their simple language. They need to avoid drawing attention to their simplistic technology and slow development process if they are to keep their management in the dark.
And, the MicroFocus company should definitely keep quiet. Their tools are indeed very cool, but they need to keep the emphasis away from the Cobol language itself lest management smell the inefficiency. Sure, the financial companies are rolling in cash and able to sustain inefficiency--but for how long?
Big, stupid, and makes life miserable for geeks. We despise its success, but that doesn't change the fact. Much to our chagrin, the smartest candidate often loses out to the more boring, popular, and simpleminded one.
'nuff said
Prov 9:8 Do not rebuke mockers or they will hate you; rebuke the wise and they will love you.
The key limitation of COBOL systems are two-fold:
The main hurdle I've found when dealing with Mainframe apps are the lack of either (or both) of these. You find these monolithic COBOL systems that have been continuously updated for over 20 years and nobody knows exactly what they do.
What's more, 20 years of changes always involves some serious "Business Logic" changes. So the data is often kludged, with pre-1995 data treated differently from pre-2000 data, treated differently from current data. What's more, there are usually about 2 people who actually "remember" all of the changes, but it was never written down, so it's stored in the deep recesses of their brain. And since 1994 was the year that docs were still written in WordPerfect for DOS, you don't have electronic copies of anything unless you can find a dusty printout in an old binder somewhere.
Oh yeah, and the two people who have been there for 20 years. They're too busy to really impart their knowledge to the batch of people replacing the system. And really, why do they want to obsolete themselves? Why go outside of their comfort zone? Why write all of these documents and undergo this whole process when the current system "works just fine" and I only have 5 years to retirement?
So what's the reality? Most companies I've met have been taking shortcuts on their development processes for years. They kludge the code, fail to clean up, fail to date (or sometimes even comment) code and then they fail to document all of the changes.
As we all know that these shortcuts save time now at the expense of time later. Well if you've been writing cheques from the "later" account (as most companies are wont to do), then you're eventually so far behind that you simply can't recover.
Let's face it, if you had an exact spec for the functioning of your COBOL system, then conversion would not be a big deal. It would be time-consuming, but it wouldn't be "hard". But if you don't have a spec, then programming is not the issue at all. Without the spec all you have is a system with [un]known bugs and 20 years of vaguely understood changes.
I've heard of people developing systems to refactor COBOL code, but this is just another kludge. Porting code just gives you bad code in another language, the goal is always to port concepts, which is why domain experts are so key.
So basically, without Domain Experts and quality Documentation, COBOL systems will continue to exist. Without these two pieces the "upgrade" is basically impossible.
Some of the scariest shit I've ever seen. The old parts are written in COBOL, a pile of over 4000 scripts with 6 character filenames that work together to form an ERP system. It originally used flat files to store records, with multiple record types in each file. At some point they managed to upgrade to a real database server without significant code changes, which means multiple record types, with completely different fields, in each table. It updates database records using the ever popular "delete and reinsert without any atomicity" method, occasionally (dozens of times) deleting a major customer's records because it crashed while updating them. New parts of the ERP system are written in VB6, and store much of their data in Access databases, despite that there's a perfectly good database server they could use. At one point I wrote a script to monitor one of the Access databases and backup and repair it each time it became corrupted.
COBOL is just a very small part of an (IBM) puzzle; you say COBOL, but you mean COBOL, CICS, OS/390 architecture, mainframe terminals, that protocol that goes in between them, that horrible tree-based database architecture, MQ-server etc. etc. etc.
Religion is what happens when nature strikes and groupthink goes wrong.
Comment removed based on user account deletion
There's no point in this, because you're not filling a need. This is like developing a car for the Amish. It's not that they can't get a car, its that they don't want a car. If the COBOL shops had an interest in changing tools, they would have done so some time between 1959 and now.
Someone with a huge pile of COBOL doesn't care about language features, expressibility, or whatever else is out there. If they wanted any of that they would switch. They care about shareholder value and ROI, which dictate that "change nothing" is cheaper than "rewrite everything".
but I never compiled!
My sense is LISP is the exception because it wasnt a core commercial language, save for an A.I. business bubble in the 80s. Academics tend to rewrite their codes more often. Or more precisely each generation of energetic grad student re-invents the next great system, but only writes 80% of it.
Two great tastes that taste great together ... too bad there's not a free COBOL .NET for Mono - if people could hack COBOL (don't laugh, there's an Emacs editing mode for it, ask me how I know) on a Linux box, they'd be more apt to learn it. If I saw there was a demand for COBOL programmers, I would buy Mike Murach's book and work through it with my Mono COBOL compiler. The real problem is there's no open-source COBOL compiler. IBM has COBOL compilers. They ought to take one of them, retarget the back end code generator for Mono or the JVM, and release it under AlphaWorks or something. Then people could learn COBOL very easily. (I know IBM had a COBOL compiler for OS/2 and Windows - they could almost release it as-is for the x86 Linux architecture. I mean, you'd have to change the I/O calls to use UNIX-style I/O, but you can almost be sure the runtime library is written in C and could be ported easily.) That's my beef - there's a skills shortage!!! Well, why not release better tools so people can learn? Not everyone has a mainframe. Although I guess you could get an old VS COBOL II tape image and run it under the MVS 3.8 turnkey Hercules system....
Just to twist knickers, there's Object-oriented COBOL running on the Java Virtual Machine.
Can we get a "-1 Wrong" moderation option?
1895: Ada Lovelace discovers the calculator is more fun than Charles Babbage
1950: COBOL is born; world celebrates
1953: FORTRAN is born; revenge on COBOL
1957: Death of COBOL predicted
1963: BASIC is born; a language for people who do counting on their fingers
1965: Death of FORTRAN predicted
1966: C is on the horizon
1973: Death of COBOL predicted
1974: Pascal is born; competition with C
1977: C is born; revenge on FORTRAN
1979: Ada is born; revenge on Charles Babbage
1982: Death of FORTRAN predicted
1985: Death of Charles Babbage predicted
1986: Death of COBOL predicted
1991: Charles Babbage legally pronounced dead
1993: Death of BASIC predicted
1997: merging of C and C++ into new language D
2001: dark monolith discovered on Jupiter moon; determined to be an old COBOL card deck for an accounts receivable program
2002: COBOL reborn as COBOL++
2010: Death of Pascal predicted
One reason COBOL works well is that it supports decimal numbers and decimal arithemetic. No sane financial guy is going to let you use floating point (i.e. Approximate numerics) in financial calculations. This makes it very difficult to migrate any of the work the COBOL code is doing into other laguages.
Your forgetting Scotty's Laws, which required you as an engineer to maintain your miracle worker image while supporting the captain of the ship in his image that he understands everything that is going on. COmmon Business Oriented Language was in part developed with this in mind and to allow some code discussion with the accountants and financial workers necessary to deliver the required design. Now when the CEO demands to see something of the code, well that's no problem, "sure mr. ceo, will take an x hour printing run to get you that and will have it delivered to you", print it out, ship the boxes of printed materials to the CEO, keep in mind these are huge boxes with all the pages about the size of a desk calendar ( you know, the ones that lay down and cover most of the desk), thousands upon thousands of pages, all with easily recognizable words on them. All the CEOs closest subordinates will assure him its readily understandable to them, accounting will assure him they understand it, finance will assure him they understand it, but there he sits in his office filled with boxes of printouts and scratches his head, sure he understands some of the words on the printouts but,,,,. The CEO may even call up the IT head for some discussion but even with him he will be trying not to let out how clueless he is about something on his ship, in the end all the printouts get returned to IT and the miracle workers are left alone.
Now if these programs were done in other languages, no one but IT would pretend to understand it and the CEO would feel free to say "this is gibberish, give me something I understand, I am required to watch over you guys." The selling point on computers in those days was that they replaced bookkeepers, accountants and some financial people with lower paid data entry clerks etc.
Its like the guy that has two cars. He has a 1976 Volvo with 300,000 miles that runs fine and gets him from A to B in a reasonable manner. He drives this Volvo to work, to run errands, and it performs its job routinely without fail. When he wants to go out run 150 mph down the autobahn he takes out his Ferrari instead. Just because something is old and not efficient for a one task doesn't mean it still isn't efficient for what it was designed. Would I develop alot of new apps in COBOL? Probably not but that doesn't mean that every line of COBOL needs to be converted. COBOL for business transaction oriented apps, especially batch applications, is quite sufficient. It is easy to learn, easy to maintain when documented, and portable.
Funny, I thought it was "Confusion Oriented Business Obfuscation Language" :)
Some bring out the best in others, some the worst. Some bring out far more.
It's more like "because the people who would have to make the decision to replace it don't care about the bugs and see no point spending money on a replacement". They have low-paid grunts to take care of the bugs for them - and the labour costs are insignificant compared to the cost of the maintainance contract on that hardware.
That's because on a mainframe (at least a zSeries), they're already running in one! I love the mainframe's HW virtualization support. And think! It's only been around forty-some years! F*ckin' Intel/AMD newbs...
That is all.
Just merge C, Ruby, & COBOL syntax into one compiler.
.NET is; it's a bunch of front-ends and a single back-end compiler. And it can handle those language, plus Java (and probably Perl 6 as well).
That's roughly what
Integrating structure I/O and databases into programming languages was a fad in the 60's and 70's. Even Pascal and C ended up having embedded SQL.
People moved away from it because they realized that it was better to give people general purpose language constructs rather than hardcode a bunch of database code into the language compiler.
I'm always fascinated by the programming language debates here at Slashdot. They don't make any sense to me.
English is a terrible, confusing mess of a spoken language (and not so great written). Some of the Asian languages are written language monstrosities. Modern Japanese has four alphabets (including romanji)! Esperanto allegedly fixes all that. So we'll all be speaking and writing Esperanto any day now, right? No.
COBOL thrives because it gets its job done, and it has an enormous (and growing -- 2 billion net new lines each year) installed value. That's not going to change any time soon although, just like English, COBOL will evolve.
Speaking of evolution, there's an awful lot of dated knowledge about COBOL in this long discussion. It's hard to know where to begin to address that. Looking just at the relatively recent IBM stuff, modern COBOL (called "Enterprise COBOL" in IBM parlance) is now object oriented (if you want or need), has language syntax to parse and generate XML, and has well specified cross-language calling conventions in every direction you can imagine (COBOL to Java, Java to COBOL, C to COBOL, COBOL to C, etc.) The environmentals and tooling keep getting more and more interesting, and that's probably a lot more important than the language itself. Something called WebSphere Developer for System z puts all COBOL development onto a graphical Eclipse framework. (Want to set a breakpoint? Drag a stop sign. Can't remember what verb comes next? Use Code Assist. Want to map copybooks to/from XML? Drag and drop.) No more TSO/ISPF/PF12 stuff (unless you want). The IBM Debug Tool U&AF has great code coverage measurements as you test. Application Performance Analyzer lets you peer into all your code to tweak it and optimize it extremely rigorously. Fault Analyzer zeros in on exactly where an abend occurred and helps you figure out what was going on in order to quickly fix the problem. The source code libraries/change management tools (SCLM, Endevor, Panvalet, ChangeMan, etc.) are first rate for team development and, at least in the case of SCLM and Endevor, plug into WebSphere Developer for z so you can do check-ins/check-outs from your PC. The testing tools (IBM's or Compuware's) are also first rate and keep getting better. You can even do many wild things most other languages can't, like instantiate COBOL as EJBs running inside WebSphere Application Server for z/OS alongside Java EJBs, interoperating transparently and as full peers. Re: Linux (including mainframe Linux), AccuCOBOL, a commercial compiler, seems to be getting reasonably popular. For code analysis and understanding IBM's WebSphere Studio Asset Analyzer, Asset Transformation Workbench, and CICS Interdependency Analyzer are all quite helpful, and I don't think I've seen that level of sophistication in comparable tools for other programming languages. It's probably also worth mentioning Language Environment, which puts COBOL on the same common runtime foundation as every other programming language for tracing, debugging, abend analysis, etc. LE started about 20 years ago, but it has evolved and matured quite nicely and keeps getting better.
I would like to see a 64-bit z/OS COBOL compiler. IBM hasn't pulled the trigger yet, out of an abundance of caution I think. (COBOL requirements tend to get driven by "we're going to need it in X years" rather than "wouldn't it be cool to have?" And I think we're only just getting into the time when direct support for 64-bit data structures looks like it might be moving into the "need soon" category.) C, C++, Assembler (obviously), and Java have all already made the leap on z/OS, so my suspicion is that COBOL is next. Note that 64-bit v. 31-bit -- yes, 31-bit -- isn't really the same issue as on other machines. You can mix 64-bit and 31-bit code freely on z/OS, including cross calling conventions. The only issue is whether a single address space running a COBOL program can itself contain a 64-bit data object of some kind. Right now that's 1.8 GB of data objects, or thereabouts.
Dude you have never see the results of a COBOL to C translator before have you. We used one to migrate some of our store systems form COBOL ot C. The result is something we call C-BOL. You have C code but each of the WORKING-STORAGE SECTION. Paragraphs are made into structs, and any place you did a move by name or somehting results in an even crazier union. Trust me you don't really want to go this way...
Repeal the 17th Amendment TODAY! Also Please Read http://www.gnu.org/philosophy/right-to-read.html
Uhh... CICS... please don't remind me of it... CICS was the last straw that made me decide networking was for me programming was not... The fewer reminders of that nightmare the better... Heck the fewer the number of times I have to remember trying to debug 150k line COBOL apps that spill out onto 30 or 40 pages of paper (which was 'easier' to read than the IDE interfaces window on screen) the better...
we are all invisible unless we choose otherwise
... I can program in C/C++, Pascal/Delphi, Java, VB/Basic, Perl, a bit of Ruby, Python, and several shell scripting languages/applications like sed/awk. I find cobol to be the most obnoxious pain in the ass language I've ever used. I had to take two semesters of it in college and I hate it. I hate it just like I hate RPG. They're underpowered, obnoxious, and annoying to work with. Screw cobol, screw rpg. I'd sooner bag groceries than program in either language.
Shadus
I am surprised no one has found this: http://www.opencobol.org/
... if we are going to talk about capitalization.
Co_mmon B_usiness O_riented L_anguage
For_mula Tran_slator
will find the SUBTRACT TOTAL-EXPENSES form better.
Except my memory is that it is more likely to be
SUBTRACT 1200-TOTAL-EXPENSES FROM 5000-GROSS-SALES GIVING 3300-NET-PROFIT.
where the 1200, the 5000, and the 3300 are essentially scoping prefixes. Managed by the programmer according to the coding rules.
I remember RPG. I had thought the rest of the world might have forgotten it.
But, yeah, the real reason CoBOL sticks is that the suits don't like scope in their rules, and when they have to have it, they prefer it to be explicit.
Cobol was a hack to begin with. 5 years after the authors created it, they got together and stated publicly, that their efforts in creating the language were quick and dirty solutions. They never expected it to last longer than 6 months, at which time they expected something (almost anything) better would come along, and that if they expected that it would last as long as it did, they would have bothered doing a better job of it. Certainly all of the 'divisions' could easily be replaced with a simple variable list, and insistence on the formatting (line 12, line 80 and all that rot) could easily be done away with, as all modern languages have a whitespace eater in the command parser which is easy to implement. The lexical analyzer works just as well with the whitespace eater in place too, and is often easier to implement. The whitespace eater is about 10 lines of assembly. Cobol should have died in 1999. I know pundits will pound about how its critical and all that, but really, its all just assembly at the bottom (assembly being the mnemonics of machine code), and if you say your computer doesn't do that, well then, it doesn't have a processor now does it! Seriously, a Cobol2C translator should have been created and used (and sure, if a bug turns up, fix it), 35 years ago. I vote to make it mandatory that COBOL not be allowed to be installed on new hardware. When the vacuum tube beasts you old-timers insist on running finally break down, the COBOL can go with them. Modern languages for silicon based semiconductors I say! Let the dinosaurs and their ways of thinking go in the same direction.
MULTIPLY 9190-B BY 9190-B GIVING 9190-B-SQUARED. .5.
MULTIPLY 4 BY 4320-A GIVING 4320-FOUR-A.
MULTIPLY 4320-FOUR-A BY 9180-C GIVING 9190-FOUR-A-C.
SUBTRACT 9190-FOUR-A-C FROM 9190-B-SQUARED GIVING 1000-RESULT-1.
COMPUTE 1000-RESULT-2 = 1000-RESULT-1 **
SUBTRACT 9190-B FROM 1000-RESULT-2 GIVING 77340-NUMERATOR.
MULTIPLY 2 BY 4320-A GIVING 77340-DENOMINATOR.
DIVIDE 77340-NUMERATOR BY 77340-DENOMINATOR GIVING 5500-X.
Only if you have such tools and they happen to conform to the coding standards favored by your current bosses.
Only in business could coding standards be an acceptable substitute for automatic scoping rules.
Of course, no modern language gets automatic scoping right, either, so even if the suits didn't like global/explicit scope on everything, what modern languages provide really isn't enough of an improvement.
Precisely because nobody understands the rules well enough to dare rewrite.
Business rules do change, and the old business rules never were really correct, just close enough for the time and then they got momentum.
Still, to make a real replacement for CoBOL, we need to make the syntax for subprograms part of the language and fix the overhead so that subprograms can be called with no more penalty than procedure calls in Pascal. That, and make the linkage work so subprograms will be re-entrant.
Trying to make PROCEDURE calls re-entrant will break too much.
CoBOL code inherently has serious problems emulating context sensitivity.
That's why it can be so fast. You can't really parse with it, you can only run batch.
Unless, of course, your program implements a stack or two and your coding rules make everyone go to the stacks for private variables.
Oh, I'm sorry you completely brainless boob, but several points: Linux runs on supercomputers... MOST OF THEM, including all of the top ten for the past several years. SUPERCOMPUTERS EAT MAINFRAMES FOR BREAKFAST LUNCH AND DINNER! The throughput of a measly little mainframe IS PITHY COMPARED TO A SUPERCOMPUTER! Secondly, there is NOTHING wrong with the uptime of Linux. Years, decades, no problem. As for 'typical linux box' do you mean this: http://www.sgi.com/products/servers/altix/4000/ ? ,and BTW, Linux runs very well on IBM mainframes too (when Linux was ported to the mainframe, sales of mainframes went up for the first time in years). Be careful about biting the hand that feeds you! Upmty indeed, what a clod!
You make it sound like something from microsoft, and are WAY OUT TO LUNCH! As for COBOL, it does nothing that ANY OTHER MODERN LANGUAGE CAN ALSO DO! Read carefully about what "TURING COMPLETE" means before spouting off again. You may have never heard of it before, but your level of education may be your limiting factor. Oh
One of the best kept secrets on the early ARPANET (which was supposed to be for official use only) was the INFO-COBOL@MIT-MC mailing list. It has absolutely nothing to do with COBOL -- it was for jokes and other funny stuff. It was called INFO-COBOL because at the time, emailing jokes was considered an abuse of the ARPANET.
Occasionally some rube would stumble across it in the "list of lists" INTEREST-GROUPS.TXT, and ask a question about COBOL, and everybody would laugh uproariously at them -- the idea that somebody would actually consider using COBOL was even funnier than most of the jokes people posted.
Then there was another stealth mailing list maintained by The TTY of Geoffrey S Goodfellow, called "DB-LOVERS", which was specifically for Dead Baby Jokes.
-Don
Take a look and feel free: http://www.PieMenu.com
Why? Do you have some facts that support your position?
First off most ATM software was not written in COBOL. However problems with COBOL
1) No anonymous data structures
2) No typing on points, essentially only a void pointer
2') Pointing to various types of dynamic or statically allocated structures is quite complex
3) Weak conditionals
4) No first class functions
5) No recursion
6) Limited variable constructors
7) No garbage collection
8) No obvious parse trees (yet another problem with build DSL in COBOL)
I could go on but that list works for now
...the "write once" has already been done.
Translating to red gems make your debugging easy — as in, you can now do some in Ruby instead of burying your COBOL in printouts & holding a scrying glass up against the results.
Got time? Spend some of it coding or testing
In comparing languages, it might be wise to remember that most of code written in any language was written by programmers, the vast majority of which never took the time to understand the languages in which they code; remember, the 80-20 rule applies virtually anywhere. It has been estimated that becoming a good programmer in any language takes 4-10 years. Most of those old COBOL programs were written by people just as motivated, dedicated and knowledgable as today's programmers. What has changed is the environment. In the early days of computing, practitioners didn't have the tools, training and techniques in any language that they have now; in many cases, much of what was being programmed was being done for the first time, ever. And the biggest COBOL facing programmers maintaining COBOL programs has little to do with the language, it has to do with the maintenance of the records pertaining to the application, particularly the state of the available source code. In that regard, with few, if any, exceptions, COBOL's supposedly verbose syntax is self-documenting, as it was intended to be. Frankly, most of the negative comments I've seen have been made by people with only limited knowledge or experience in COBOL. Another factor in the decline of COBOL is that it was used predominantly on mainframes; when minicomputers (remember them?) came along, it took some time for full versions of the COBOL compiler to be implemented on them, so applications were written in other languages. Today's COBOL compilers, like those from Acucorp, Fujitsu and Microfocus, to name a few, offer facilities, functionality, ease of use and productivity that are equal to or exceed that of many other languages. As in many other fields, apples-to-apples comparisons are often difficult to verify, and are often clouded by the experiences of those doing the comparisons: one man's fish is often another man's poison, and not alwasy within the realm of objectivity. I've found that most of what are commonly described as COBOL's faults or weaknesses are simply opinions based on a limited knowledge of COBOL versus other languages. Remember, it pays to know what end of the horse is doing the talking.
I'm not sure what schools you went to, but both times I went for CS I had to take four cobol classes. This was between 2-10 years ago.
Posting Anonymously for obvious reasons ...
I've seen C++ code that bills non-exactly all over the place. If it was just adding stuff up, fair dos, but this crap applies rates. Well the prgrammers did try, and certain obvious problems are trapped.
Fixed point maths. Never heard of it mate !!!!!
Something that has not been said yet in this thread (and a few days late) is that COBOL is designed and controled. "The initial specifications for COBOL were presented in a report of the executive committee of CODASYL committee in April of 1960..." HERE COBOL Language features and syntax is designed for the purposes that Business needs and wants.
1. Works Well, Efficient
2. Easy to use
And so on. Architecture, modern design, OO, and so on are not really in the mix. The reason that COBOL has remained stable for so long is because it is in the interest of Business. The programmers do not have to re-learn a new language every two years. The OS does not require massive upgrades (think XP, Vista) every 4 or 5 years. Stability saves money.
as an intern for the DNR in alaska, my job is to do the grunt work of 'webifying' a ~21 year old COBOL database system. the back end isnt being changed, but the application is getting a java and jsp front end so that the forms can be used over the internet with something like modern a GUI.