×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

COBOL Will Outlive Us All

Soulskill posted about a year ago | from the lords-of-cobol-hear-our-prayers dept.

Programming 318

jfruh writes "Here's an old computer science joke: What's the difference between hardware and software? If you use hardware long enough, it breaks. If you use software long enough, it works. The truth behind that is the reason that so much decades-old COBOL code is out there still driving crucial applications at banks and other huge companies. Many attempts to replace COBOL applications flopped in the 1980s and '90s, and we're stuck with them for the foreseeable future — but the Baby Boomers who wrote all that code are now retiring en masse."

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

318 comments

Batch (5, Informative)

mwvdlee (775178) | about a year ago | (#42881369)

Well... that and the fact that COBOL is actually very good at what it was made to do; batch file processing.

Re:Batch (5, Funny)

grh_angelone (1269828) | about a year ago | (#42881427)

I hate it. Stupidest language of all time. I'm trying to convert all these crap programs to nicely done RPG IV, but its a Don Quijote task. I hate the fact, that file access can only be done in 50 lines of code. String operations are total nonsense, ever tried to get a string rightaligned? RPG file access via chain is done in 5-6 lines including the definition of the file and rightalign via evalr().

Re:Batch (4, Informative)

mwvdlee (775178) | about a year ago | (#42881525)

Yes, I'm sure it's much easier to code in RPG. In Java/C++/PHP/C# you could probably do it in less than a dozen lines of code as well. But none of those come close to the performance of COBOL for these specific tasks.

As far as right-aligning a string; it's supported in the data division: http://mainframewizard.com/content/cobol-just-right-clause [mainframewizard.com] . I'm sure if I had to program RPG without any training or a manual, I wouldn't produce very good code either.

COBOL is bad at a lot of things and in a lot of ways, but it does have a few redeeming qualities. It just turns out those particular qualities are highly sought after in many large companies.

Re:Batch (5, Informative)

grh_angelone (1269828) | about a year ago | (#42881637)

ok, this doesn't bring us any further, but do you really think, that moving something in a right justified variable is the solution?

this doesn't only need another variable, but if your source value has trailing spaces you will need a ridiculously long INSPECT line and an index variable for a substring.
since cobol is dumb, you will further need an INITIALIZE for both variables.

cobol:
01 var1 PIC X(50)
01 var2 PIC X(50) justified right
01 sub PIC 9(2)
initialize var1 var2 sub
move "test " to var1
initialize var1 tallying sub for trailing space
if sub = 0
move var1 to var2
else
move var1(1:sub) to var2
end-if

rpg:
d var1 s 50a
d var2 s 50a
c eval var1='test '
c evalr var2=%trim(var1)

seems way more convinient :)
even tough RPG is ill-reputed as an old static programming language this looks somehow like any other high level language and anyone should understand what's going on here without trying to figure out what that strange INSPECT does

Re:Batch (5, Funny)

johnnyb (4816) | about a year ago | (#42882319)

The real problem with COBOL is that, as Larry Wall has pointed out, you can't write poetry with it. There just isn't any good poetry that starts out with IDENTIFICATION SECTION.

The one thing I do miss about COBOL is easy access to fixed-point numeric processing. This seems like a no-brainer, but it is still missing from nearly every language.

Re:Batch (1)

jythie (914043) | about a year ago | (#42882063)

I am skeptical of COBOL actually preforming types of tasks quicker then other languages. Every year the compilers for the most active languages get better and better, while the COBOL one has pretty much stood still for a long time.

Obligatory tagline (1)

Anonymous Coward | about a year ago | (#42882389)

SHOOT ME I KNOW COBOL

Re:Batch (3, Insightful)

sycodon (149926) | about a year ago | (#42882421)

You miss the whole point if COBOL, which is to provide a language that clearly explains what's going on while it's doing it. That means that a freshly graduated I.S guy can go in and understand what's going on and make changes.

Sure, you can wire God Awful code with it and, I have seen it, but it doesn't take much effort to do it right.

Re:Batch (2, Insightful)

Nerdfest (867930) | about a year ago | (#42881499)

It is no batter at 'batch' processing than any other language. The reason there's still so much of it around is that the majority is hacked together spaghetti written by people who should not have been writing code in the first place; tightly coupled code that people cannot easily replace a component at a time. Earlier attempts to replace the code generally failed because they attempted to use the same people who wrote the COBOL systems to write the replacements. It is a language that is used to allow systems to be written by people who should not be coding in general. Yes people write bad code in all languages, but COBOL is an enabler, just as (in other ways) Visual Basic and Perl are.

Re:Batch (3, Insightful)

ixarux (1652631) | about a year ago | (#42881843)

^ This, I would agree with.
COBOL is not a great programming language, and people who are experts in it are NOT good programmers per se. It definitely worked well back in the days, and we should appreciate its use, but let us not let nostalgia tinge the garbage that was useful a long time ago, and now just sits there as the elephant that no one cares to move around, gently tended by the cheap Asian labour... and has no exploits because it doesn't really move around a lot.

Re:Batch (0)

SuperDre (982372) | about a year ago | (#42882017)

good/bad writing code is all in the eye of the beholder...... What you call good code can look like utter crap to another developer, and ofcourse the opposite is true too... There is no right and there is no wrong...

Re:Batch (3, Interesting)

Nerdfest (867930) | about a year ago | (#42882227)

Good or bad programming is not defined by the 'style', it's defined by it's readability, maintainability, reusability and efficiency. Yes, there is a right and wrong. Not black and white right and wrong, but certainly tending towards it. Much COBOL code was written by people who didn't understand that either. It works, and solves the immedaite problem in many cases, but it's a difficult to maintain, difficult to read, tangled mess. Yes, there is well written COBOL, but in my experience, it's rare. Personally, I find even well written COBOL difficult to read because of the verbosity. It's like reading a long paragraph of instructions, where a point form list would be easier to read and understand.

Re:Batch (5, Insightful)

jellomizer (103300) | about a year ago | (#42881509)

No, the language doesn't matter. It is the fact that the COBOL code is old. When it was popular it was common for organizations to write their own software. This custom written software was molded to fit the companies processes and workflow. Then you add decades of alterations and the software gets very complex, however it nearly covers the full operation.

So now if you are going to replace it, right now it is popular to get these "enterprise" solutions that are so generic that it takes more work to configure it than it does to make new software or port the code in a new language.

As well most organizations just don't know why they need to upgrade they just think they do, and after the upgrade they want a program to do exactly what the last one did.

Re:Batch (5, Insightful)

peragrin (659227) | about a year ago | (#42881777)

That because the cost of retraining people in new workflows is generally higher than the software package to begin with.

If you gut and replace software you have to modify every employee's workflow to compensate. EVERY person has to do their job slightly differently, and no one has the answers as to how it all has to be worked out from the beginning for each part.

That takes months in a small 20 person organization that is flexible and adaptable. It can take years of lost productivity for larger ones.

I am doing it right now. We are gutting our old ERP system to use a much simplier but ultimately more useful ERP system. Everything from sales, accounting, purchasing, warehousing, inventory, delivery drivers, all have to change how they process their paperwork. We basically had the office staff doing 2 days of nothing as we sorted out bugs with the initial data transfer. Now that is done we begin the task of sorting out workflows, new SOPs, etc.

Re:Batch (2)

dywolf (2673597) | about a year ago | (#42882153)

in other words, if ain't broke, don't fix it. just keep the guy that wrote it on retainer (or else he'll retire, then come back as a consultant for 5x the salary), and pay him explicitly to train the new guy.

or else don't buy generic stuff, but hire a -good- code monkey to go through and develop the new program, in parallel with the old (ie, staff dont see the new one til it's completely done, outside of occasional small group tests...with some classic A/B iterations)

Re:Batch (1)

asylumx (881307) | about a year ago | (#42882417)

So now if you are going to replace it, right now it is popular to get these "enterprise" solutions that are so generic that it takes more work to configure it than it does to make new software or port the code in a new language.

Tell me about it! It doesn't have to be COBOL. Why is our company stuck on 20 year old RPG code? For the same reason that in 5 years it will be stuck on 25 year old RPG code. Because it does what we need and it's a royal pain to try to replace.

Re:Batch (5, Informative)

Anonymous Coward | about a year ago | (#42881687)

No. COBOL was designed for taking simple decimal (BCD) representations of quantities and financial amounts, conducting basic arithmetic operations on those and transferring the result back to storage or line-printer-style reports.

It is still the basis of a great many online, interactive applications as a result of the development of OLTP systems that were intended to provide "real time" transactions on top of old legacy batch procedures. CICS in particular is alive and well and nothing to do with batch processing - though its interactivity is largely achieved by having the display terminal emulate the fixed fields of punched cards and line printer columns - and although it has support for several languages, COBOL is where it found its natural home.

There's nothing magical or mysterious about COBOL (apart, perhaps, from the MOVE CORRESPONDING statement) - it's a procedural programming language that works with simple representations of data. The idea that a modern generation of programmers can't understand it is ludicrous and anyone that suggests rewriting swathes of code simply to change the syntax of its representation doesn't understand the first principles of software engineering.

COBOL is here to stay in both batch and interactive applications.

Re:Batch (2)

LoRdTAW (99712) | about a year ago | (#42882271)

COBOL may be decades old but there are still young people taking up COBOL programming. I have a friend who is around 30 now. He was a CS major in university and one of his professors recommended he learn COBOL. He told me it is the most valuable and useless programming languages you could learn. Out of university he got a job with a company doing contract work for IBM doing guess what? COBOL code maintenance. Now he is living in California making six figures working for a big financial institution maintaining and writing COBOL. Not so useless now, is it?

More work for me (1)

Anonymous Coward | about a year ago | (#42881383)

I code in Java but I'm also not above coding in an old language. My C skills are one of the main reasons I'm valued where I work. I did learn some COBOL at one stage and remember thinking it was tedious...but I'd happily pick it up and apply my knowledge to it.

So Simple! (4, Interesting)

Grindalf (1089511) | about a year ago | (#42881391)

Writing COBOL is not just easy, it's fun! It takes about a fortnight to work through the manual and become fluent. It uses very English like syntax. It's much easier than FORTRAN or C as it's so small! Lets face it in this world of UNIX massively parallel cloud social web computing, this is hardly a complex problem to solve – it's already been done by the folks that wrote COBOL. A simple database! So get that manual out, and have a try!

Re:So Simple! (4, Funny)

paiute (550198) | about a year ago | (#42881941)

So get that manual out, and have a try!

These seem to me like famous last words, almost as dangerous as the classic "Hold my beer and watch this!"

Re:So Simple! (0)

Anonymous Coward | about a year ago | (#42882081)

So get that manual out, and have a try!

It sure is easy to learn and it sure will outlive us all by centuries: http://abstrusegoose.com/323

If a technology is outdated, outsource it. (5, Interesting)

ixarux (1652631) | about a year ago | (#42881409)

Yup. I was hired into one of those mainframe companies that worked with COBOL and JCL. The work was the most menial of works I had ever done(after they trained me for 6 months in it).
The financial sector, the lumbering dinosaur that accepts change only when they have no other option, and the ones maintaining decades-old mainframes really have no incentive to change technologies at the moment. It's easier to just outsource the maintenance and servicing of the mainframes. There are enough of coders (like in the company I joined) in developing countries across the world who would gladly take it up.
From my experience, there is little development happening any more. I think the day when they run out of people who want to this crappy menial job (which is never) is the day COBOL will go extinct.

Re:If a technology is outdated, outsource it. (1)

Grindalf (1089511) | about a year ago | (#42881423)

JCL, is that the one from Digital's VAXen? I've had some fun with that beast before ... Ah nostalgia ...

Re:If a technology is outdated, outsource it. (2)

DarkOx (621550) | about a year ago | (#42881513)

No IBM brought us JCL. So after writing you "business friendly" COBOL program. It was certain you would still need to find a wizard of the highest order to run it. Only he could convince the Gods Zeek and Zed to turn your program into a living process instead of some mere bytes on on a virtual tape somewhere

Re:If a technology is outdated, outsource it. (1)

Grindalf (1089511) | about a year ago | (#42881553)

I'm laughing. It was not VAX “Job Control Language”! So Zeek and Zed must be the Gods of “Zee” OS. Smart A wing tip wizard is required in your analogy, in effect ...

Re:If a technology is outdated, outsource it. (1)

Silfax (1246468) | about a year ago | (#42882313)

The VAX had DCL - Digital Command Language, and as far as JCL goes, it is essentially a method of setting up environment variables so programs can access external resources, a shell script - nothing more.

I don't remember ever seeing Zeke & Zack (not Zeek & Zed) on a Z/OS system - If I recall they were mostly on VSE systems and were a automated operator/scheduler. I can't remember which was which, it has been a long time since I have worked on VSE, Z/OS is a daily thing.

Re:If a technology is outdated, outsource it. (1)

nospam007 (722110) | about a year ago | (#42881551)

"JCL, is that the one from Digital's VAXen? "

Most modern Dispatch stations in Europe still run their trains on OpenVMS (ESTW) because the original program was running on VAXes 40 years ago. Just like the space shuttle, they can't easily change the program because each change has to undergo security evaluations that just cost too much money and time.
Each signal, crossing etc is still operated via 2 modems each to report their status.

Re:If a technology is outdated, outsource it. (2, Insightful)

Anonymous Coward | about a year ago | (#42881437)

"The financial sector, the lumbering dinosaur that accepts change only when they have no other option"

You mean one of the first industries to start using computers commercially? Way before your glorious NASA?

Re:If a technology is outdated, outsource it. (2)

Grindalf (1089511) | about a year ago | (#42881449)

My understanding is that the financial sector does “cost based analysis” which is that the work goes to whoever buys the project's budgetary accountant the best meal – plus or minus capability. :0)

Re:If a technology is outdated, outsource it. (0)

Anonymous Coward | about a year ago | (#42881467)

Given NASA isn't exactly a commercial enterprise that's hardly surprising.

Re:If a technology is outdated, outsource it. (0, Insightful)

Anonymous Coward | about a year ago | (#42881501)

I knew you nerds would nitpick that. But the fact remains, we have computers today largely because they are useful on their own, not because we needed to put a few test pilots in rubber suits on the Moon to impress the Commies back in '69. I get so tired of the fact-free emotional religious ranting of the space fringe.

Re:If a technology is outdated, outsource it. (-1)

Anonymous Coward | about a year ago | (#42881561)

I mean I like NASA as much as the next nerd, but the drooling retards and their "we only have computers because of NASA" refrain are tiresome. Especially when NASA itself admits that computers existed way before we needed to explode tons of kerosene out of large metal tubes.

http://www.youtube.com/watch?v=EollNAmgwKA [youtube.com]

Re:If a technology is outdated, outsource it. (-1)

Anonymous Coward | about a year ago | (#42881851)

Why do you try to make sending a rocket ship into space sound unimpressive?
Are you such a fag that people giving NASA credit bothers you so much you want to try to discredit the space race? Oh yeah buddy we were just showing off for the Russians
It was literally that unimportant /sarcasm. You're a retard, read a history book

Re:If a technology is outdated, outsource it. (0)

Anonymous Coward | about a year ago | (#42881483)

One of the first, The first being a tea shop [wikipedia.org]

Re:If a technology is outdated, outsource it. (5, Interesting)

jandersen (462034) | about a year ago | (#42881917)

So, you didn't like to work on a mainframe, then?

But don't slag off the mainframe just because it is 'old' technology - the PC architecture isn't all that young either, and the mainframe, believe it or not, is in fact very VERY much on the technological forefront, hardware wise. Mainframes had fiber attached disks before most modern developers had heard of networking.

Big to huge institutions don't use mainframes because they are too backwards thinking, but because of reliability. In an industry where downtime costs millions to tens of millions per minute, that counts a lot. On a mainfram you can hot-swap just about everything - not just disks, but everything. And if you wish, you can run Linux on it as well; but it is amazing how often the choice is MVS and COBOL; that is because they are just what you need - not multitools like UNIX and C, just a plain old knife meant for cutting only.

Lords of COBOL (5, Funny)

ae1294 (1547521) | about a year ago | (#42881451)

All of this has happened before and will happen again...

Re:Lords of COBOL (3, Funny)

Anonymous Coward | about a year ago | (#42881865)

Not to me it wont! As an ex cobol programmer I have a no resuscitation card for cobol emergencies card to be buried with me.

Re:Lords of COBOL (1)

a_hanso (1891616) | about a year ago | (#42882365)

I came here just to point out that "The scriptures say that COBOL points the way". I'm glad to see someone else had the same idea.

Quality Assurance (0)

Anonymous Coward | about a year ago | (#42881469)

I use to make a living rewriting these solutions to suit modern platforms. In my experience, it wasn't the language that made these solutions great pieces of engineering, I think it was either better programmers or a better culture regarding quality, maybe they were better motivated? I for one would love to see what some of these guys could have done if they just had a bit of syntactic sugar to sweeten their code to get around some of the clever but ugly hacks we've all seen.

If it aint broke... (4, Interesting)

detain (687995) | about a year ago | (#42881515)

why bother paying tons of money developing new software, going through the painful growth and ironing out all the bugs of the new software, educating people on the new software, importing your current clients into new software, getting modern hardware to run the new software, installing modern networking equpment for the new hardware to run the new software, etc.. theres just no real reason to upgrade the software. There won't be many new exploits for COBOL based software as well, since its not used by the average person.

Re:If it aint broke... (0)

Anonymous Coward | about a year ago | (#42881573)

I agree... except... in this case the answer is:

Because it is broke!

Re:If it aint broke... (0)

Anonymous Coward | about a year ago | (#42881765)

The people who wrote the COBOL were real programmers, who also had clear goals, and understood the data.
There are cross language converters - say COBOL to PASCAL/ADA like here: http://www.mpsinc.com/cobol.html.
Clear thinking people.But the language is irrelevant, management has it in for real programmers, because they cost more than click and drag monkeys who only know one 'product', and believe the marketing spin that with XYZ enterprise database engine, any change is easy and cheap.

Now you have visual programmers who can't code, but fully get the eye candy and forms bit, but no idea what they are doing, other than chunking out code to specifications, which often resembles a spreadsheet. You have DBA's who have turned off relational integrity checking, and enterprise architecture that goes out of date in months.

With COBOL, you can only build up to your competency. With modern shite, you can dream up anything, and say yes to anything, but just don't expect it to work too long, or stay 'cheap' one you are hooked to voracious vendors.

Re:If it aint broke... (1, Insightful)

jkflying (2190798) | about a year ago | (#42881607)

Why rewrite to something that is modular and well designed? Because it is impossible to add any new features to the old system without inadvertently breaking everything else.

Re:If it aint broke... (4, Insightful)

Anonymous Coward | about a year ago | (#42881715)

My guess is that a rewrite will not give you something modular and well designed, it will more likely result in a reformatting of all the data into millions of incomprehensible XML files.

Not old hardware, new hardware (1)

Anonymous Coward | about a year ago | (#42881663)

I belive that all larger mainframe customers run on modern hardware. Mainframes are still developed and upgrade regulary. You can even run previous version togheter with current version of the hardware in your mainframe cluster. Additional machines can be hot added and work migrated live between the machines.

Mainframe have all the bells and whistels of the "cloud" and have had for several years.

My work place recently replaced the tape storage system to a new one, or rather the 2 tape storage systems as we run geographically disperesed clusters of mainframe in order to provide guaranteed uninterruptable service.

Re:Not old hardware, new hardware (0)

Anonymous Coward | about a year ago | (#42882155)

Not true, Our company specialise in supporting a number of customers that use older legacy systems and in house developed software, one of which is a large international customer (that shall remain nameless, but you will be familiar with), who use mini computers and micro computers that were assembled in the late 1970s / early 1980s, they use a language not dissimilar to cobol, that was created in the mid sixties.

Because of the nature of older hardware, assuming you can still source individual components (i.e. electrolytics, capacitors, etc), the computers can be repaired. Take a modern system, and everything is surface mount these days, which means when a board fails, it has to be replaced. What happens when the manufacturer stops producing these boards? You are forced to upgrade! This is no trivial job, as many companies that still use these legacy systems have had hundreds of man years worth of development spent on the software. You can't just rewrite this software, in many cases the cost runs into hundreds of millions, and in some industries (more specifically with control systems), you have to consider safety, environment, and the fact that government bodies might have to sign on to updating many of the systems in certain industries after rigorous testing. And I've not even mentioned the fact that many process/service industries need to have years of downtime to replace their some systems.

What tends to happen quite often is that modern peripherals are attached to the legacy systems, e.g. we have compact flash cards / SCSI disks attached to some legacy systems where there where once Winchester disks with interchangeable platters), there are specialist companies that produce equipment to interface the different generations of equipment.

There is little incentive to update these systems due to high cost involved or in some cases it's just quite simply impossible. There will always be opportunities for companies that can bridge the gap, and it's a lucrative market to be in, as we can demand high rates due to the scarcity of skills (for which we have an active internal staff development programme), but still offer massive savings to our customers.

Re:Not old hardware, new hardware (1)

Mabhatter (126906) | about a year ago | (#42882179)

More importantly, upgrading Mainframes if you stay on track, is easier than buying a new PC and having all your stuff copied over. Today's mainframes are DESIGNED to be upgraded/replaced easily. As long as you have your source code and stay on the manufacturer's track it's easier to replace than to migrate... Like staff needs counted on fingers easy.. Even for multi million dollar machines.

Re:If it aint broke... (0)

Anonymous Coward | about a year ago | (#42881695)

At a guess, companies reaching the limits of scalability of ancient software? Or does COBOL stuff in the financial industry scale pretty well?

Re:If it aint broke... (1)

Anonymous Coward | about a year ago | (#42881821)

Cobol isn't the most interesting part of the enviorment. It's the eco system around it as well. z/OS, MVS, IMS, CICS and so forth are built for large volumes from the begining on very limited hardware. So from the beging there was a scaling problem and they solved it early on.

You can for example run batches in partions or in modern lingu sharded. If your current mainframe works fulltime 'just' add another on and you have a larger sysplex (modern lingu cluster). If that grows out, add another one and so forth. When you reached the maximum number of machines IBM have probably released a new generation so you can upgrade by replacing your existing machines on by one.

So problems of scale in finaciall institution are common and solved on daily basis due to the fact they run mainframes.

Re:If it aint broke... (1)

Anonymous Coward | about a year ago | (#42881769)

> getting modern hardware to run the new software, installing modern networking equpment for the new hardware to

Banks don't run old hardware or networks, CoBOL runs fine on the latest hardware thank very much

Have a look at Micro Focus, it will run CoBOL on .Net CLR and a JVM

Re:If it aint broke... (2)

91degrees (207121) | about a year ago | (#42881901)

Source compatibility is pretty common, but aren't the current bank computers binary compatible with the early 360's from the 1960's?

Re:If it aint broke... (2)

gutnor (872759) | about a year ago | (#42881799)

Do you really want to pretend that all the change we have had in software like browser, os, databases, search algorithm, storage, network algorithm, and countless other area have has no impact at all ?

The reason the Bank do not change a working software is that by the time the software really works (i.e. 10+ years after the initial design), nobody really knows why it is working - if you are lucky. Most of the time the company has also lost the knowledge of how it is working too. Changing it becomes a huge risk - since you don't know why it is working, you will never be sure the new system is behaving like the old one. Also since you have lost the why, you just can't design a new better system.

In an age where a company like Google is able to run analytics on the whole internet, that sites like facebook can instantaneously know what was your favorite brand of pasta in June 2007, do you really think Banks are happy to have whole floor of admin people check by hand that one of their own client has not requested the same mortgage in 2 different branches ? No need to be even that technical, would they just happy to have a system that support space in surname and accented characters so that you do not have to implement training session, guideline book, review processes, special compliance validation to work around that limitation that after 30 years in business now affects 30% of their clients.

Re:If it aint broke... (4, Insightful)

DarkOx (621550) | about a year ago | (#42881905)

The character set limitations are really platform issues not issues with COBOL or even in most cases the programs written it in. Honestly I have never understood all the COBOL hate. Sure it fails to deliver on its promises of letting business folks write code without any domain specific training in software develop. Just like every other language that has approached that challenge mostly BASIC or Object BASIC dialects.

That said I'd be actually pretty surprised if a good C/C++/Java/Ruby/Python/PHP/whatever guy could put together a program to do something like print a fifty million decent looking telephone bill statements with accurate summary lines for transaction-data as quickly as a COBOL programer of similar skill and experience can. There really are some problems COBOL solves well. Bulk record processing and account reconciliation is one of those things because that was pretty much THE commercial and military logistics application for computers in the LATE 40's when COBOL was born. COBOL as you might expect is quite fit for that application.

Its when people start trying to do interactive applications in COBOL be it CICS or web or whatever it gets silly and forced. It brings to mind various analogies about square pegs for round holes, and threaded fasteners to be deployed by hammer. Its sorta like how people tried to CGI applications in C for a long time in the webs early days. Sure it worked and if C was all you knew I suppose you could get the job done. C is good at many things, large amounts of string manipulation is not one of them; but its something you need for a dynamic website. Does that make C a bad tool, no, it just means its the wrong application for it.

Re:If it aint broke... (3, Insightful)

gutnor (872759) | about a year ago | (#42882401)

BTW, this is not a COBOL hate, that is a "if it ain't broke ..." hate.

Argument like there is training required, there will be bug, ... are generally not the cause at all. The real cause is that the company lost the very business knowledge that is abstracted by the software. Worse, most of the time that knowledge has been outsourced to other third party completely.

The 2 problems highlighted could be solved, even in Cobol. They won't be solved, and the reason is not that new software cannot be better, it is that the company has lost the knowledge of its own core business and is unwilling to take any real measure to learn it back. Most of the time, "If it ain't broke ..." is not wisdom, it is a sign of incompetence as bad as "Nobody has ever been been fired for buying IBM".

Re:If it aint broke... (0)

Anonymous Coward | about a year ago | (#42882239)

Bullshit. The mainframe vendors and programmers pionered all of that except browsers. Show me a modern OS featuer outside the graphics system that didn't ship on a mainframe first. Oh by the way, if facebook or google are wrong, nobody cares. If your bank is wrong, you have a severe emotional event.

Re:If it aint broke... (0)

Anonymous Coward | about a year ago | (#42881877)

Because if this were the case companies like Microsoft would just roll over and die. This is the reason why they are changing very rapidly to software rental instead of fixed software sales. Right now I go into a bank and all the terminals are XP pro workstations and the big iron running them is not something that gets switched out frequently or has the server software changed.

If you really examine what is happening the use of simple robust reliable software with menu driven easy guis that have not changed over to a full blown windows api video centric icon driven gui is hurting them big time. AND FOR VERY GOOD REASON

I remember a food warehouse that was sold an awful windows api style inventory interface. If an order for ketchup came in you scrolled down to the ketchup icon to access the correct sku and bring up the stock list from the db, then if you had an order for that item the visible ketchup bottle icon added it to the shipping list for an order. My guess is they thought that guys who work in a warehouse can't even spell or use their brain at all...assholes!

NEEDLESS to say it was a friggin' nightmare hung the servers and only lasted 3 months before the guy at head office that bought it was canned and the old system was put back in place.

And this is the issue at hand Microsoft relies upon the concept that one needs to see everything and not have any essential skills to use Windows software, whereas in reality the speed and accuracy at which good old typing search terminal based guis can work will never be replace by touch screen or icon based interfaces. In some ways keyboard terminal programs are the very best solution to complex item based db access and manipulation.

It is obvious that most programmers have never actually worked in a real world environment like a warehouse especially corporate spin doctor CEOs like Steve Ballmer and his ilk. Forest meet the trees.

COBOL was supposed to be a quick fix (3, Interesting)

Required Snark (1702878) | about a year ago | (#42881521)

COBOL was defined by the "Short Range Committee". It was never intended to last.

there it was decided to set up three committees: short, intermediate and long range (the last one was never actually formed). It was the Short Range Committee, chaired by Joseph Wegstein of the US National Bureau of Standards, that during the following months created a description of the first version of COBOL. The committee was formed to recommend a short range approach to a common business language.

http://en.wikipedia.org/wiki/COBOL [wikipedia.org]

Not replacing, wrapping... (0)

Anonymous Coward | about a year ago | (#42881555)

While it is true that many companies run mission critical COBOL applications, they are very well aware of the issues that this poses. Many IT shops approach them proposing to replace existing applications which doesn't make any economic sense whatsoever... the risk associated with such a project makes it a no-starter.

What smart IT shops are doing is proposing to "modernize" existing infrastructure. The way it's done is with analyzing key "services" that existing apps provide and then "wrapping" them with modern technologies such as web-services. This way it's easy to build modern UIs on top (HTML5, Mobile apps etc) as well as build another backend for new functionality under the same new UI. From the business's perspective it looks like an entirely new application with a modern UI and the ability to add features while at the same time not assuming the tremendous risk of retiring existing apps.

The premise of the article is that there will always be COBOL jobs but the reality is that the approach I describe doesn't really require any COBOL knowledge (or hardly any).

COBOL Rocks. (0)

Anonymous Coward | about a year ago | (#42881595)

One of the things that I seriously loved about COBOL was the basic English structure of it. Properly written, you (the programmer) could sit down with an actual USER, who was not a programmer, and debug it. In my opinion, one of the biggest advantages of COBOL, from the organizational point of view, is that it was so easily maintained.

Spaghetti code? That's an absolutely crap thought process to dislike an entire language because of poor coders. Those exist with every language.

It exists, because its good. Simple as that.

Every 3 to 5 years. (5, Insightful)

sgrover (1167171) | about a year ago | (#42881599)

Every 3 to 5 years this topic comes up. It's almost like some new batch of CompSci graduates start to evaluate the state of the industry, and share their "discoveries" with the world. Except it is the same old discoveries couched in modern terms.

Re:Every 3 to 5 years. (5, Insightful)

mvdwege (243851) | about a year ago | (#42881681)

That's because IT is suffused with a teenage culture that equates 'old' with 'useless'.

Being able to spew the buzzwords related to the newest fad seems to be a requirement for a dev job these days.

It doesn't help that the industry as a whole (especially in the US) seems to prey on young naive workers and likes to keep them that way in order to extract the maximum profit out of them.

Re:Every 3 to 5 years. (0)

Anonymous Coward | about a year ago | (#42881733)

That's because IT is suffused with a teenage culture that equates 'old' with 'useless'.

Being able to spew the buzzwords related to the newest fad seems to be a requirement for a dev job these days.

It doesn't help that the industry as a whole (especially in the US) seems to prey on young naive workers and likes to keep them that way in order to extract the maximum profit out of them.

Ruby!

Gawd, an interpreted language that makes Java look screaming fast.

Re:Every 3 to 5 years. (0)

Anonymous Coward | about a year ago | (#42881883)

Crowdsourcing customer-facing solutions in node.js that are cloud-driven and hyperscalable!

Can I have $130k/year and all the Rockstar I can drink?

Re:Every 3 to 5 years. (1)

a_hanso (1891616) | about a year ago | (#42882377)

Every 3 to 5 years this topic comes up... Except it is the same old discoveries couched in modern terms.

Pythia does say that all this has happened before and will happen again. COBOL is where it all began.

Outdated? Maybe Not (1)

Anonymous Coward | about a year ago | (#42881665)

One of the things that continues to fascinate me is the tendency of computer folks to create new programming languages -- claiming to be 'better' than their predicessors for solving problems but most often just different and frequently worse. Compared to the development issues I have experiences writing C, C++, shell scripts, various assemblers and macro languages, Fortran, APL, various Basics, Forth, Focal and many others whos names I have forgotten over the last 50 years, Cobol was trivial both to write and to generate. Wordy but boring, it just did its job. If I were doing an accounting application it would just make sense to use something like Cobol. Problem is that with IT, marketers are continually dusting off and renaming old ideas -- new doesn't necessarily mean better. Sometimes old just means it works. And the word obsolete gets thrown around a lot -- especially with regards to Cobol. Have any of us ever really questioned what it means? Obsolete in my mind means replaced by better approaches, not just different, Effectively it seems to mean paid for and understood, therefor bad, from the perspective of those folks who make their living from selling stuff. From an implementers perspective, and the businesses that pay for it, there is a lot to say for suitability for a purpose.

COBOL is a work of genius (5, Insightful)

sirwired (27582) | about a year ago | (#42881679)

Viewed through the eyes of a modern programmer, COBOL is indeed a joke. A horrible one. It violates nearly every single principle of good language design in what appears to be a misguided attempt to make programming "friendly." A CS undergrad would get a poor grade turning in something like COBOL as a Programming Languages 101 project.

But for a language first specified in 1959 (when computing didn't even have the Integrated Circuit yet), it's a work of staggering genius; they didn't HAVE all those rules of good language design to fall back on! At the time, FORTRAN had been out for all of two years and LISP for one; hardly enough time to have much experience with knowing what not to do, and neither of those languages targeted the same problem domain.

COBOL made modern computing accessible and useful to businesses. It's programs have maintained decent backwards compatibility for about half a century. And for all it's foibles, all those hundreds of millions of lines of COBOL actually work. They may be a disgusting kludge, a result of decades of compromises, but these gigantic black boxes of spaghetti Work. And there's no reason to think they'll stop doing so any time soon. Nor any reason to believe that replacing them would be in any way cost-effective.

"Good" issubjective. Perl is worse (1)

Anonymous Coward | about a year ago | (#42882183)

It violates nearly every single principle of good language design...

Whose principles are those? (That was rhetorical)

they didn't HAVE all those rules of good language design...

Again whose rules? (That was rhetorical, too)

There are no physical laws and mathematical rules that state what good design is. None. There are some folks who promoted themselves as being the "ones who know what's correct" but there are no "rules".

If the code:

  1. Works as designed.
  2. Easy to ubderstand.
  3. Easy to maintain.

then the code and language is a wonderful design. Everything else is arbitrary.

Because using the standards expressed in the parent, Perl is the biggest piece of shit EVAR!

I witnessed an argument in a CS class years ago between the professor (he started it by being a condescending prick) and a student who had a MSEE and being forced to take the class (C++) because his years of embedded design and coding in C++ didn't count because he didn't have a class in it. When the engineer pressed the professor about these "rules" and logically analyzed them, the professor being intellectually beat, said in exasperation, "It's the way _I_ want it! OK!?"

So, whenever I see folks spouting off about these rules, they are parroting something for a professor or from a book by an "expert" or it the way they think it should be.

Cheer up... (0)

Anonymous Coward | about a year ago | (#42881721)

...these days there's JAVA for the masochists!

COBOL Will Outlive Us All (0)

Anonymous Coward | about a year ago | (#42881731)

COBOL.

cockroach.

I think it's pretty obvious.

I don't think there will be a shortage. (1)

OpenSourced (323149) | about a year ago | (#42881737)

It takes a week for a programmer to learn COBOL. A month at most to be proficient. Of course depending on dialect and environment, it can take more to be productive, but that's true also for COBOL programmers coming from other backgrounds. That means there will be no big shortage of programmers as big companies can train in-house in a matter of days.

The problem with COBOL is that it will erode your sanity with mindless repetition and superfluous verbosity. If you are put to make COBOL programs, make a generator for the most common tasks. It won't save you perhaps such a big amount of time, but it'll make life more interesting.

Training? *hollow laugh* (1)

Rande (255599) | about a year ago | (#42881781)

For those teams that actually get a training budget, it'll be 2 days for one member of the 10 strong team per year. I last got training that I didn't pay for myself in 2000.

Re:Training? *hollow laugh* (1)

necro81 (917438) | about a year ago | (#42882415)

That was one of my reactions to the article as well. This line from the end of page 1:

...other companies will make the decision to recruit and, if needed, train a new generation of programmers

We've seen for quite a few years that many companies expect new employees to "hit the ground running", with nothing more than a cursory new employee orientation. Training, especially on-the-job training and formal mentorship/apprenticeship models, have largely fallen by the wayside. In other words, hiring managers want employees who have all the skills to do exactly the job the company needs, in exactly the way they think they need it done. Then they are surprised when they can't find someone who exactly matches that profile.

[For the record, I am not one of the bitter long-term unemployed who have been stung by this. I was schooled in engineering, got hired as an engineer right out of school, and am happily employed as such today. But I am cognizant of the largely artificial obstacles that many of my peers face]

Re:I don't think there will be a shortage. (2)

CrazyBusError (530694) | about a year ago | (#42882071)

Sorry, but I'm going to have to disagree with you. You can learn basic cobol in a week, sure. You can probably even learn all the useful keywords in a month, but almost certainly won't learn all their options or the best way to use them or the caveats of using some of them. You won't learn the various gotchas waiting in the wings when defining data structures either, whether in memory, or on disk.

A month might make you able to write fairly complex stuff, but it won't give you time to learn the best ways to write efficient fast code and COBOL, despite its apparent simplicity, is remarkably easy to write nasty (self modifying if you wish) resource-hogging evilness. If you're on mainframes, it'll be longer than that before you've figured the full intrigues of things like Expediter, or, if you're really unlucky, core dumps, which can be your only way to debug.

I've worked with COBOL since the mid 90s, so I'm still considered a noob in the field, but I've seen some horrors written by people with twice the experience I have and I've rarely seen *good* code written by people with anything less than a year of it on their CV.

Bear in mind also that most COBOL is mainframe still, so chances are that as well as the language itself, you're going to have to learn DB2, JCL, CICS and suchlike. Mainframe assembly will also likely crop up in your radar and in certain financial institutions, PL/1 - all linked into one big horrible mess. You might think you'll learn COBOL in a week, but almost no company using it for mission-critical stuff will let you within a mile of their production systems until you've a couple of years under your belt.

COBOL is a glue language on the mainframe (0)

Anonymous Coward | about a year ago | (#42881833)

Not just COBOL! What people don't understand is COBOL is the glue language of the mainframe. COBOL is the easiest and most productive way to write CICS, IMS, DB2, MQ, etc applications. Sure, you can use other languages, but IBM has invested decades in making their technologies easy to access from COBOL.

What is going to hurt is the brain drain when people retire who are experts in IBM's huge, over-engineered technologies like CICS, IMS, and DB2. A reasonably motivated programmer could get a Mike Murach book and learn enough COBOL to be productive in a fairly short time. What is going to be difficult to replace are people who know CICS, which is an operating system within an operating system and inhumanly complex.

And, since you can't run CICS on Linux, how would you learn it? About the only way to learn it is to get a job working with mainframes, but of course employers only want experts with 5+ years experience. Eventually, maybe they'll get desperate enough to train someone. There's the rub: The short-sighted technology industry has let two or three GENERATIONS come along and learn Linux and Java. Everyone has been chasing the existing CICS experts, not making more. Now, generations have never used an IBM mainframe. If a company started today training in-house programmers, it could take years to develop a new generation of CICS experts. That's what you get for being short-sighted and focusing only on the next quarter.

I hope the impending brain drain hurts companies so bad, and causes them to lose so much money, that they start investing in training once more.

Re:COBOL is a glue language on the mainframe (1)

RabidReindeer (2625839) | about a year ago | (#42882135)

I won't argue that business has spent far too long only recruiting people who can "hit the ground running" and sawing the bottom rungs off the career ladder. However, there's a reason that lack of CICS expertise isn't killing us all.

The mainframe isn't dead, but it's no longer essential. Much of the real work these days gets done using servers, and HTTP servers actually have many functional similarities to CICS, Both are designed to provide terminal presentation and input. Both are geared towards fast request/response turnaround. Both have the ability to hook into back-end services such as databases.

While IBM is certainly supportive of CICS, they're also quite happy to sell you WebSphere to do many of the same things, and typically talking to the same backend systems. MQ very definitely hooks into JMS, and I've worked with several J2EE apps whose database services came from DB2.

CICS is complex, but then again, so are modern-day industrial-strength non-mainframe platforms. The bigger problem is that business has spent too much time shopping for talent at Wal-Mart.

Re:COBOL is a glue language on the mainframe (1)

jythie (914043) | about a year ago | (#42882147)

Maybe someone needs to write a mainframe emulator for linux? I know I have seen projects out there for things like ITS and Multics.

Re: COBOL is a glue language on the mainframe (0)

Anonymous Coward | about a year ago | (#42882195)

I got a job right out of college to be trained for literally months of paid classes for the problems you state. The workforce is aging and we are expected to end up replacing them. There is so much to learn. Some were literally rocket scientists.

Speaking of COBOL outliving us all... (4, Interesting)

fuzzyfuzzyfungus (1223518) | about a year ago | (#42881859)

Does anybody know what language(s) are used for the "Dead Hand" second-strike control system that the Russians were working on during the Cold War? Personally, I'd nominate them as the programming languages that will outlive us all...

Hire veteran COBOLers, retirements won't matter. (5, Insightful)

emes (240193) | about a year ago | (#42881899)

It is a bromide perpetrated by ITAA and business groups that we can't find enough programmers to replace the ones who are retiring.

The simple truth is that no one wants to PAY what people are worth, and there is rampant age discrimination:

http://www.itbusinessedge.com/cm/blogs/tennant/yes-age-discrimination-is-worse-in-it-than-in-other-fields/?cs=38549 [itbusinessedge.com]

Be willing to hire, retrain, or do whatever it takes to employ people over 35 and this so-called problem will be
shown to be the chimera that it really is.

Re:Hire veteran COBOLers, retirements won't matter (2)

jythie (914043) | about a year ago | (#42882125)

That would help yes, but another part of the problem is, with these older technologies, many companies are only interested in drop-in replacements. There are few (if any) companies out there taking on entry or mid level developers for mainframe stuff, so once the current crop of experienced people run out they are going to be in trouble.

Here's an old computer science joke (2)

RabidReindeer (2625839) | about a year ago | (#42882025)

"Here's an old computer science joke: What's the difference between hardware and software? If you use hardware long enough, it breaks. If you use software long enough, it works.

Actually, that's not true. COBOL programs are more durable because the COBOL architecture is very simple. Almost all of the work other than raw I/O was done in the COBOL code itself. Modern-day systems are heavily dependent on many external components, almost all of which are constantly evolving. So the "if it ain't broke, don't fix it" approach is actually more of a "how long can you afford to delay upgrading before the whole thing collapses beyond repair?"

Even legacy programs didn't actually get better with time. Once you reach a certain point, it's more like you move the bugs around. The old "pressing on a ballon" analogy goes way back.

"... great entry-point into IT." Seriously? (0)

Anonymous Coward | about a year ago | (#42882049)

It's not about COBOL. It's about knowing something about mainframe programming that would get you the job.

http://stackoverflow.com/questions/4433165/learning-cobol-without-access-to-mainframe

Job Postings (3, Funny)

jythie (914043) | about a year ago | (#42882105)

Heh. In my job search I have actually been, well, surprised might not be the right word, but amused, at all the COBOL, FORTRAN, and mainframe postings. One thing I think they are getting themselves into trouble with though is all the postings I have seen require decades of experience in the technology, so they seem to be trying to replace retiring boomers with similarly skilled people, but not creating entry level or training paths.

There are only 3 COBOL programs... (3, Interesting)

DrogMan (708650) | about a year ago | (#42882129)

The "Input and Validate"
The "Update"
and the "Print"

At least that's what a lecturer told me many years ago when I did COBOL at uny. I didn't get on with it initially, then I got bored and opened the book... Then I learned that what the lecturer was telling me was his idea of what COBOL ought to look like and not generic. It got a little more interesting after that (along with the student competition to see how many errors we could make the compiler generate with the minimal amount of syntax errors - one mis-placed full-stop managed to get it to the limit of 999 once)

I've not written a COBOL program for over 30 years now. I don't miss it.

-G

Well, of course COBOL is still around (3, Funny)

MikeLip (797771) | about a year ago | (#42882225)

As a guy who worked on some pretty complex financial software, I can tell you this; If you come to a company and say "Hey, look. Your software is outdated, and just not cool anymore. Let us fix it." They will say "OK, how much will it cost, how many times will you screw up (and you WILL) and how much will it cost in lost productivity, development and training time?" In other words, prove to me that the cost and risk outweighs the benefits of leaving my not-cool but working structure in place? Know what? You can't. When you are talking about financials, companies are justifiably VERY risk-averse. And yeah, people laughed at COBOL when I was coding, and even back in the 70s when I was learning. This is an old argument and the fact is COBOL will be around a very long time whether our new compsci grads like it much or not. They aren't paying the bills and looking at cash flow. They just see all that legacy code and say they could do it better. Maybe you can. But you're not gonna.

COBOL is bad (0)

Anonymous Coward | about a year ago | (#42882285)

MAINLINE.
          PERFORM WHINE-WHINE-PROCESS UNTIL COMPUTERS-DIE = 'Y'.
          STOP-RUN.

WHINE-WHINE-PROCESS.
          DISPLAY 'COBOL is ancient.'.
          DISPLAY 'COBOL is something my grandfather wrote.'.
          DISPLAY 'COBOL is wordy.'.
          DISPLAY 'COBOL code is spaghetti code.'.
          DISPLAY 'All COBOL programmers will eventually die or retire.'.
          DISPLAY 'COBOL is only used by banks and insurance companies.'.
          DISPLAY 'COBOL is hard to use when compared with a modern language like java.'.
          DISPLAY 'COBOL is hard to use when compared to C++.'.

         

Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...