IBM Takes System/z To the Cloud With COBOL Update

hypnosec writes "IBM is taking its COBOL server platform to the next level by updating the mainframe platform in a bid to extend and enable its mainframes to host cloud based applications and services. The latest update is looking to add XMLS Server as well as Java 7 capabilities to the System/z COBOL platform and this update would extend the overall lifespan of COBOL by taking it up a notch and gearing it towards the cloud computing arena."

Comments

Anyone?

[Anonymous Coward]

A stake and garlic? Anyone?

Re:Anyone?

[Freddybear]

mmmm, steak and garlic. Oh, wait...

Re:Anyone?

[Anonymous Coward]

Call Hellboy.

Re:Anyone?

[iggymanz]

to kill that java server EE off?

COBOL on the other hand has well designed base of apps that have stood the test of time and still process the most important financial transactions

Re:Anyone?

[Aighearach]

        PERFORM 3 TIMES
              DISPLAY "Die!" WITH NO ADVANCING
        END-PERFORM.
        STOP RUN.

Re:Anyone?

[93 Escort Wagon]

COBOL on the other hand has well designed base of apps that have stood the test of time and still process the most important financial transactions

Not to mention a mean developer age of 73...

Re:Anyone?

[ebno-10db]

Not to mention a mean developer age of 73...

Get off of my lawn, sonny. If it was good enough for Grace Hopper, it's good enough for me. BTW, do you want to get paid next month, or should I put a bug fix into that code I wrote 40 years ago?

Re:Anyone?

[Anonymous Coward]

Don't forget the holy water!

Re:Anyone?

[Anonymous Coward]

What's hilarious, is that as a not a developer, that was perfectly readable. Is that actually COBOL?

Re:Anyone?

[Anonymous Coward]

As someone who has done COBOL a long time ago, I have no idea if everything fits but it reads like it.

Re:Anyone?

[JPLemme]

Yes, although there are dozens of lines of code omitted (ENVIRONMENT DIVISION), and in my experience COBOL's direct printing and console commands were never used. You either wrote to a file and used a third-party reporting tool to print or you interacted with the screen using CICS. But I imagine if the commands were really never used they'd have been deprecated by now, so YMMV.

Re:Anyone?

[non-e-moose]

Wait - you forgot the 3 pages of required COBOL prologue to create a "hello world" style program.

Re:Anyone?

[Anonymous Coward]

Wait - you forgot the 3 pages of required COBOL prologue to create a "hello world" style program.

In fairness, half a megabyte of .js, a thousand Java classes, and Glub knows what those C# people do... maybe the Cloud really is the Mainframe 2.0. We've come full circle.

Re:Anyone?

[Jeremy Erwin]

Elizabeth Taylor's phone number was BUtterfield 8.
The IRS can be reached at VAmpire 9-1040

Re:Anyone?

[Anonymous Coward]

A steak and garlic sounds like tasty supper, NO! No, what you need is something thermonuclear, or better yet: very black, very cold, and with a very very high gravitational field. IBM would try to upgrade it so that it can escape the event horizon, but you must persist. Even if they manage to get the C part out, you have at least got rid of the OBOL (and C on its own is good). I like C. The rest must: DIE! DIE! DIE!

Re:Anyone?

[OhANameWhatName]

is that as a not a developer, that was perfectly readable. Is that actually COBOL

Pretty much. Try translating it into any other language and making it readabe. That's something that all of the snarkers will never know about COBOL .. it actually encourages the use of extremely self explanatory variable names and code which is easily readable. File format definitions in COBOL far surpass anything which has happened since (in terms of configuration readability and changability) and printed output can be generated like butter. 88 levels (by definition) make code more readable .. and no other language has ever integrated this concept.

If you have a look at reporting today, there's nothing as capable as COBOL at spitting out reams upon reams of reports. The kind of regulatory reporting required by governments and tax agencies. Trying pushing 30,000 pages out of any modern reporting software and see how far you get. COBOL systems chew up and spit out this kind of work. It's not a question of the cost of upgrading to something better, if you need 20 boxes of paper reports .. there is nothing to replace COBOL.

The haters will hate and there's 2 bazillion idealistic programmers all lined up behind them laughing at COBOL's flaws. If you want it to die, you'll need to replace it first. Because to date, nobody's done that .. 50 YEARS.

And BTW: If you want to earn a shedload of cash as a contractor, there's no better language to learn.

Re:Anyone?

[Anonymous Coward]

You must be a COBOL newbie. You need a space after each "Die!" otherwise it'll look ugly :-)

Re:Anyone?

[Anonymous Coward]

for i = 1 to 3
        print "Die!",
next

Is that somehow less readable than the COBOL?

Re:Anyone?

[Aighearach]

I hate to admit knowing this, but modern COBOL lets you omit most of that. Depending on the exact compiler used, you might be able to omit all the boilerplate. But even stricter ones let you keep it to 3 or 5 lines, something in that ballpark. Not really less boilerplate than most compiled languages.

That said though, it was a snippet not a program so nothing was forgotten or omitted.

Re:Anyone?

[Blaskowicz]

"next" is less explanatory that something like "endfor".
That "i" variable goes unused.
You have to know what that comma means, and actually I think you should have written print "Die!";

Re:Anyone?

[schnell]

Clearly COBOL will never die. As I recall, the civilization of Battelstar Galactica had an entire religion devoted to the "Lords of COBOL." Not just the colonists, but I'm pretty sure I saw in one of the deleted scenes an older-model Cylon Raider trailing punch cards from a hull breach.

Re:Anyone?

[robbiedo]

mmmm...steak, onion, and mushrooms with a sprig parsley. What were we talking about?

Re:Anyone?

[robbiedo]

BACCE has been around forever, too.

Re:Anyone?

[countach]

OK, but... who the heck wants 20 boxes of paper reports?

Re:Anyone?

[pipatron]

print "Die!" foreach 1..3;

Re:Anyone?

[OhANameWhatName]

who the heck wants 20 boxes of paper reports?

Pretty much anyone trying to hide something.

Re:Anyone?

[Anonymous Coward]

> in my experience ....

Your experience seems to to be limited entirely to mainframe batch or quasi-batch CICS.

For the last 45 years (since 1978) there have been COBOL compilers for Unix, desktop (CP/M, MS-DOS) and other mini and micro systems. These use X/Open and other extensions to ACCEPT/DISPLAY to create fully interactive programs, or use 3rd party libraries for graphics.

30 years ago I developed a fully graphical Windows (3.1, then '95 and 'NT) container ship loading system entirely in COBOL. It had a graphic display of the ship's bays, tanks, a helm view, had bending and shearing graphs and could even do a fly-by.

COBOL isn't just for processing punch cards (though I did that too in the late 60s and early 70s.

Re:Anyone?

[flargleblarg]

3 {(Die) show} repeat

Re:Anyone?

[crutchy]

is that "=" for assignment or comparison?

Re:Anyone?

[dkf]

I'd have thought that, with a name like that, anti-zombie techniques would be more effective. Let's be careful with which type of undead we are killing here!

Re:Anyone?

[Anonymous Coward]

ENVIRONMENT DIVISION

Good lord on a donkey, but that one took me back to my college days and tuts/assignments/exams in COBOL...

Thanks for the nostalgia.

Re:Anyone?

[TeknoHog]

Not to mention a mean developer age of 73...

Get off of my lawn, sonny. If it was good enough for Grace Hopper, it's good enough for me. BTW, do you want to get paid next month, or should I put a bug fix into that code I wrote 40 years ago?

I thought "mean" referred to the arithmetic average, rather than personality...

Re:Anyone?

[baegucb]

A few off the top of my head; car registration and renewal notices, bank statements, credit card statements, paper checks for people who don't like direct deposit. Pretty much any organization with thousands or millions of customers (mostly banks, insurance companies, governments, etc.)

Re:Anyone?

[Lorens]

In my company I'd be very surprised if the mean age of the COBOL developers is over 35. But yes, of course, I work in a bank.

Re:Anyone?

[serviscope_minor]

Not to mention a mean developer age of 73...

And this is the problem with misunderstanding statistics. If you take the more informative median developer age, you'll see it's closer to 80.

Re:Anyone?

[DoctorBonzo]

What is this language? Forth?

Re:Anyone?

[Anonymous Coward]

26 year old developer here...my first development job was writing COBOL.

Re:Anyone?

[Anonymous Coward]

What's hilarious, is that as a not a developer, that was perfectly readable. Is that actually COBOL?

COBOL was designed so that PHB's could look at the code and imagine that they understood what the program did.

God help us all.

Re:Anyone?

[Anonymous Coward]

Because VB.NET is sooooooo much better.

If I had to pick a language to kill of, it would be VB.NET. At least COBOL has consistent syntax. VB.NET (any VB for that matter) is a mishmash of trendiness. First it's like SmallTalk, then it decides to be like C but then adds classes, but not without retaining it's BASIC crap. And using OCX/ActiveX controls doesn't mean you're writing Object Oriented code.

Re:Anyone?

[Anonymous Coward]

Try translating it into any other language and making it readabe.

print "Die! " x 3;

...but this does not make Perl a readable language.

Re:Anyone?

[Anonymous Coward]

I only came to appreciate COBOL when I had to port a program from COBOL to Java. This was MicroFocus COBOL running under Windows, but it's my understanding COBOL on mainframes could do the same things. The coolest thing I though was in COBOL was the concept of the CODE BOOK (I think that's what it was called). It was a way to map a a file to variables. It worked perfectly and cut out a lot of boiler plate code. I don't know why many "more modern" languages didn't implement something like this.

Nowadays you don't have much call to parse files because people use XML, but in the 1990s and earl 2000s, there was plenty of legacy data that was in flat files.

In my early days as a programmer, I met many COBOL programmers who had the hacker attitude, only they did it on a mainframe where thre was a heck of a lot more security and rules. It doesn't mean that there weren't hacks programming, but you can same the same about any language. Using a newer language doesn't make you l33t.

I, for one, have great respect for COBOL and those that programmed with it.

Re:Anyone?

[digitalchinky]

You are right, most of the COBOL devs here in Asia are not long out of college. Migration away from mainframe has become one of the more common chunks of work being outsourced over the last couple of years, seems like a rapidly growing trend. IBM might be a bit late to plug the leaks though.

Re:Anyone?

[Hognoxious]

Fresh out of college my first job was as a C0807[1] programmer. About the only thing I remember (apart from what an utterly horrid language it was) was that, according to the (c) message the compiler printed before the inevitable ten dozen syntax errors, it was older than me.

Some of the micro guys used these Fisher-Price variants you speak of. Still, unless they're so different as to be effectively something else, I can't think of anything less suitable for graphics.

[1] I will not utter it here.

Re:Anyone?

[iggymanz]

You have a misconception, mainframes and the related piece (e.g. storage, software, services) at the end of 2012 accounted for a quarter of IBM sales and half its profits.

http://www.economist.com/blogs/schumpeter/2012/09/ibms-mainframes

that's a fallacy, to think COBOL is the same as mainframes. COBOL is run on Unix, OpenVMS and Linux systems at many financial, healthcare and insurance corporations. That code isn't going anywhere, it integrates with databases and various front end Java Server EE middleware well.

Mainframes run all the common enterprise software, any and all modern languages, DBMS, middleware servers.

When the asian corporations outgrow the low end stuff they are using, and want huge scalability and massive throughput, they'll be needing mainframes.

Re:Anyone?

[i]

I would rather write:

Perform 3 times
    Display 'Die!'
.
GOBACK.

Re:Anyone?

[bws111]

More to the point - in 4Q 2012, mainframe revenue was UP 56% (in growth markets it was up 68%). In 4Q 2012, IBM shipped more mainframe MIPS than at any point in it's entire history. And HALF of those MIPS were in the form of 'new workload' (Linux, Java, DB2) engines.

Re:Anyone?

[Aaden42]

"Well designed" isn't a phrase I'd use to describe any COBOL app I've ever had the misfortune to deal with. Most have "stood the test of time" only by having an army of support staff to continuously fix data that the poorly designed and neigh unto unmaintained applications constantly mess up.

Not to say that it's the least bit difficult to write crap in Java, .NET or any other language you'd care to hire an amateur to hack on for you. That said, of the lot, COBOL is by far the most likely to leave you paying tons of money to keep the thing running and least likely to be able to find competent coders to replace an aging workforce.

Ugh

[Anonymous Coward]

Extended COBOL lifespan?!

THANKS OBAMA! :(

Re:Ugh

[DarkOx]

Never a death panel when you need one.

Re:Ugh

[ColdWetDog]

The damned thing's immortal.

IBM has found the secret to everlasting life!

Surely, there is some money to be made here?

Re:Ugh

[PolygamousRanchKid]

The damned thing's immortal.

IBM has found the secret to everlasting life!

Surely, there is some money to be made here?

Old COBOL programmers made a fortune with the year 2000 problem.

The exact same ones will make a fortune with the year 10000 problem. So, yeah, there must be some secret to everlasting life in all that COBOL stuff somewhere . . .

Re:Ugh

[ebno-10db]

The damned thing's immortal.

And C is so much different? COBOL may be 54 years old, but C is not exactly a kid at 44. Sure we've had updated versions and C++, but so has COBOL (COBOL 2002 is OO). BTW, I've loved C since I first started using it, and I'm not sure I'd even recognize COBOL if it fell on me (not just a figure of speech if you're using big card decks), but just saying.

Old programming languages never die (at least once entrenched), but this zombie effect wasn't appreciated when COBOL was first spec'd, because HLL's hadn't been around long enough. The fact that in 1959 COBOL was supposed to be just the first of three successive language definitions is instructive. From Wikipedia:

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. The committee was made up of members representing six computer manufacturers and three government agencies. ... The intermediate-range committee was formed but never became operational. In the end a sub-committee of the Short Range Committee developed the specifications of the COBOL language.

Re:Ugh

[jd2112]

The damned thing's immortal.

IBM has found the secret to everlasting life!

Surely, there is some money to be made here?

Have you seen how much a maintenance contract on a Z-Series runs?

Re:Ugh

[ColdWetDog]

Have you seen how much a maintenance contract (aka Health Insurance) on YOU runs?

At the rate we're going in the US, they can afford to put your Z-series hardware on your health insurance premium as an inexpensive rider.

Re:Ugh

[Anonymous Coward]

Yes. And, given that the average zSeries machine can replace as many as 10,000 toy servers, it's a steal.

That's the reason it's still around, you know. Because none of the "cheaper" solutions have actually proven cheaper for any kind of large scale.

Re:Ugh

[gauss72]

You prefer that everybody in this industry earns a precarious income and operates dirt-cheap stuff ? No high-end equipment whatsoever ? Yeah, that makes sense if you earn about as much as a McDonalds worker. Unfortunately, I do think your wish will come true.
Regarding IBM mainframes, they are worth their money and if you cannot see the difference to the cheap x86 stuff from Dell, that's your fault. Finally, every skilled factory worker stands in front of 500k Euros/dollars worth of hardware these days. You prefer that 10k$ Dell "server" ??

Re:Ugh

[jd2112]

You prefer that everybody in this industry earns a precarious income and operates dirt-cheap stuff ? No high-end equipment whatsoever ? Yeah, that makes sense if you earn about as much as a McDonalds worker. Unfortunately, I do think your wish will come true. Regarding IBM mainframes, they are worth their money and if you cannot see the difference to the cheap x86 stuff from Dell, that's your fault. Finally, every skilled factory worker stands in front of 500k Euros/dollars worth of hardware these days. You prefer that 10k$ Dell "server" ??

I never said that the Z series wasn't worth the money, just that that they are expensive.

Re:Ugh

[Anonymous Coward]

They (and you) missed some of it: Grace Hopper and a few others were tasked to design it. They didn't expect it would be around after 6 months. After noting that it was still around after more than 2 years, Grace reflected "If we had realised it would be around after more than 6 months we would have done a much better job of it. We could have and should have."

Re:Ugh

[Anonymous Coward]

Indeed there is. For example, charging $1000 / hour with development time of 100 hours for a report with 10 fields.

Re:Ugh

[Cyberax]

I certainly would prefer a $10k Dell server to a multi-$100k IBM shitframe. And then add redundancy with a couple of other $10k servers from Dell.

I've seen too much crap about the 'reliability' of big iron in the real world. Out here, outside of marketing brochures, IBM hardware and software quite often fails - and usually with much worse consequences. See, most people expect commodity hardware to fail and _plan_ for it.

Re:Ugh

[gauss72]

Well, I do think we have to differentiate between implementation quality, conceptual quality and manufacturing quality. The first one is definitely not very good on IBM mainframes. They are shipping products with much more bugs than Intel, HP or their own Power Unix people do. But the mainframe concept of a large centralized machine with lots of failure detection, failover, management, virtualization, massive I/O, clustering and so on is solid.
Just looking at the hardware and software cost is very short-sighted. Factor in operating, management, custom software development cost and the picture looks different. For example, if you don't have proper job control facilities, a single user can monopolize the system by accident and affect lots of different user groups/applications on the same system. Raw horsepower is only one of many important aspects.

Re:Ugh

[Anonymous Coward]

10,000 is a massive over exaggeration. We just completed our Mainframe decommission about 12 months ago. our 60,000 MIPS were replaced with 1300 cores of mid range capacity (about 50 servers), that gave us more overall processing capacity and a significantly reduced price in licensing and running costs, if we hadn't done the conversion we would have been out of business in 3 years as the mainframe while performing exceptionally well and doing everything we needed was rapidly approaching a point where we could not compete in the financial market we were in as the maintenance and licensing costs put us at too significant a cost disadvantage to our competitors. That isn't to say a mainframe doesn't have a place, but you are talking out your arse when you say none of the cheaper solutions have actually proven cheaper. before we embarked on our conversion we visited dozens of other places that had done similar conversions successfully (and a few that had failed).

Re:Ugh

[crutchy]

when cobol programs were first written...

programmer: "ok it works... just... now nobody fuck with it or it might just explode"

now...

manager: "ok it works... just... now nobody fuck with it or it might just explode"

Re:Ugh

[Cyberax]

That canard is getting old.

These days I can easily give each user a separate server, even several servers. They are freakingly cheap - I can buy decent compute nodes for a $5k apiece (and it's going to be much more powerful than a mainframe partition of the same cost). Sure, there's also the question of shared storage/database, but that is also readily solved by a multitude of NAS/DB vendors. About administration costs - it's very hard to find mainframe specialists. So just their salary can outweigh every cost advantage of a 'single' mainframe system.

I actually don't really care about manufacturing quality as long as it is good enough. I feel that we should design systems that can tolerate failures rather than trying to design infallible systems.

Re:Ugh

[Anonymous Coward]

one for one with Intel, yes it is more expensive. Anybody here run an entire business on a single Intel box, running a single instance of Windows (or even Linux) on the bare metal? If so, how big are you? We are in about 40 states (insurance). We are small shop and I run 13 OLTP regions (CICS). Anybody run 13 separate web application servers on a single OS instance on Intel? Perhaps some do. We definitely don't. We have the "a single app on a single OS instance". We do physical server consolidation with VMWare and Hyper-V.

Re:Ugh

[Anonymous Coward]

So it was like 90% of all software development projects then

What?

[lord_mike]

The latest update is looking to add XML Server as well as Java 7 capabilities to the System/z COBOL platform and this update would extend the overall lifespan of COBOL by taking it up a notch and gearing it towards the cloud computing arena.

NOOOOOOOOO!!!!! :-(

Can't we just let COBOL die with dignity? It's lived a vibrant, fruitful life. It's time to let go. It's time for COBOL to go to the great nulll device in the sky... and not the "cloud", please. The "cloud"? Seriously? It's time to move on... for everybody's sake.

Re:What?

[Samantha Wright]

It's lived a vibrant, fruitful life.

Well now it'll live another one! Like the sporocarp of a fungus growing on a bag of rotting garbage.

Truly, there can be no greater evil than COBOL and enterprise Java in the same bucket, united by an unholy sludge of XML.

Re:What?

[Freddybear]

Are you kidding? There's sixty years worth of legacy applications programs out there in COBOL.
Yeah, it sucks from a Computer Science perspective, but business programming ain't Computer Science.

Re:What?

[Anonymous Coward]

The latest update is looking to add XML Server as well as Java 7 capabilities to the System/z COBOL platform and this update would extend the overall lifespan of COBOL by taking it up a notch and gearing it towards the cloud computing arena.

NOOOOOOOOO!!!!! :-(

Can't we just let COBOL die with dignity?

Not as long as so much of the world runs on it. This summery of current usage has excellent citations showing how widely COBOL is used:

http://cis.hfcc.edu/faq/cobol

Some points from that link:
    * There are 1.5-2 million developers, globally, working with COBOL code.
    * There are around 200 billion lines of COBOL code in use.
    * Around 5 billion lines of new COBOL code are added to live systems every year.

It's lived a vibrant, fruitful life.

It's a tool to get work done, not a living thing. Competent people don't anthropomorphize their tools.

It's time for COBOL to go to the great nulll device in the sky...

Are you volunteering to pay the costs of porting 200,000,000,000 lines of code to whatever language you prefer? I thought not.

It's time to move on... for everybody's sake.

Why should anyone go to the trouble of doing that? Because a random fol on the internet doesn't like it?

Re:What?

[phantomfive]

COBOL and enterprise Java in the same bucket..........Biology questions?...Car and computer analogies available for most concepts!

How is it that a biologist has such a strong opinion on COBOL Java and XML in an enterprise environment?

Re:What?

[Milvuss]

You have no idea how many biologist you can find, working with COBOL Java and XML, because they were are very few jobs in Biology, and a lot more in Computer Engineering.

Re:What?

[Anonymous Coward]

It's lived a vibrant, fruitful life.

Well now it'll live another one! Like the sporocarp of a fungus growing on a bag of rotting garbage.

Truly, there can be no greater evil than COBOL and enterprise Java in the same bucket, united by an unholy sludge of XML.

Ignorance is........ignorance.

Re:What?

[Anonymous Coward]

... Yeah, it sucks from a Computer Science perspective.....

In what way, pray tell?

Re:What?

[Anonymous Coward]

It's a tool to get work done

Nuh uh. Programming languages are for showing how hip and cool you are not for getting work done. Using COBOL or C or C++ isn't as cool as being able to show how you wrote a new iPhone fart app in 10 lines of Ruby or Go.

Re:What?

[Anonymous Coward]

Are you kidding? There's sixty years worth of legacy applications programs out there in COBOL.

Which means that people have continued to develop systems in COBOL for at least 25 years after its sell-by date.

Oh dear.

Re:What?

[Aighearach]

If we just run with it and add a few more languages, we can bridge this thing into the next millennium.

Re:What?

[Samantha Wright]

Biology is more of a day job. Computer history is one of my hobbies. That being said, though, biology does involve a lot of Java and XML.

Re:What?

[Freddybear]

Structured programming and objects are afterthoughts. Arbitrary data structures likewise.
No first-class functions. No lambdas.

Not that your typical business report program has any use for those things.

Re:What?

[Samantha Wright]

...and so the contest to find the worst combination of server software technologies begins. I'm stuck somewhere between unmaintained metamorphic perl and a ghetto re-implementation of Excel Services.

Re:What?

[phantomfive]

biology does involve a lot of Java and XML.

That is fascinating.

Re:What?

[narcc]

Not that your typical business report program has any use for those things.

Exactly.

It's also one of the many reasons you get such incredible performance out of COBOL.

Adding objects was a stupid marketing-driven mistake.

Re:What?

[Samantha Wright]

Oh, how I wish it were.

Re:What?

[Anonymous Coward]

COBOL was never vibrant. never.

But it just fucking worked.

Re:What?

[jd2112]

It's lived a vibrant, fruitful life.

Well now it'll live another one! Like the sporocarp of a fungus growing on a bag of rotting garbage.

Truly, there can be no greater evil than COBOL and enterprise Java in the same bucket, united by an unholy sludge of XML.

If it ties to a cluster of back-end Oracle databases servicing SAP you could be right. Satan himself probably wouldn't touch that much evil.

Re:What?

[Nutria]

COBOL is a great language for it's specific domain. There's a special Hell waiting for PHBs who mandate C/C++ and Java for record-oriented business applications.

Re:What?

[Nutria]

Structured programming ... are afterthoughts.

You haven't actually written production COBOL, have you?

No first-class functions. No lambdas.

Not that your typical business report program has any use for those things.

Exactly. COBOL and FORTRAN were targeted domain-specific languages before the term was invented, and the targets weren't Edsger Dykstra.

Re:What?

[Samantha Wright]

I think that's sort of the appeal of combining COBOL and Java in one server product. Now, PHBs can use Java for record-oriented applications and COBOL for everything else. Prior to that, they'd have to pick one or the other.

How does COBOL stack up against classic VB for record handling? Or older BASICs for that matter? The BASIC family is generally held to be pretty good in that department.

Re:What?

[gauss72]

In the hands of a capable professional, objects can be at least as efficient as structures+procedures. Plus, you need a language with real destructors to immediately reclaim memory when you are done. I would argue that properly used classes and objects will improve your program in several dimensions. Think of automatically closed file and database handles when a method returns or the containing object is being destructed.
I currently work on a data analysis application which processes 32Mbyte/s of input data using C++ PER CORE. I tested it to linearly scale to 50 cores. And yeah, it works similar to a record-oriented Cobol program. Full-table scans are not as bad as they might sound. Index-oriented access is actually a very restrictive way of accessing large data sets and CS professionals should break out of the jail called "relational database". Not every lose part requires fixing by nail.

Re:What?

[Anonymous Coward]

We don't know.

Re:What?

[hairyfeet]

You know I never understood the hate for this or that language as the way I always saw it all the complaints about this or that language could be boiled down to "using it where it doesn't belong" whereas if you just would have stuck with using it where it made sense all would be chocolate and puppies.

Take VB for instance, you want to see a "real programmer" go foam at the mouth just mention VB in their presence, but if you just stuck with what VB was good at, which is building GUIs for local DBs quickly and easily? Then it was fricking great, nothing IMHO comes close to VB for that particular task.

So I just don't get the hate, i really don't. Sure the old "If all you have is a hammer everything looks like a nail" rule applies when it comes to using this or that language where it doesn't make sense but that is true of ALL languages. I bet the old COBOL guys here can probably name 3 or 4 use cases where COBOL just works brilliantly and I say good for them, you should use the right tool for the job no matter what is hip or happening today.

Re:What?

[real-modo]

How does COBOL stack up against classic VB for record handling? Or older BASICs for that matter?

Much better. The Basic family has very primitive record definition capabilities compared to Cobol.

And it completely lacks a native fixed-point decimal data type. Doing accounting is ... uncomfortable ... without one; that's perhaps the main reason that Cobol has stuck around (after the failure of PL/1 and RPG, [no, Report Program Generator]).

Re:What?

[real-modo]

...and so the contest to find the worst combination of server software technologies begins. I'm stuck somewhere between unmaintained metamorphic perl and a ghetto re-implementation of Excel Services.

PHP and ... anything? PHP is a fractal mess. Few other tools can make that claim.

Re:What?

[narcc]

In the hands of a capable professional, objects can be at least as efficient as structures+procedures

That makes my point, doesn't it? To say that, under the best of circumstances, objects can sometimes be as efficient isn't much of a defense. (Let's not forget that you often trade far more than just performance for objects.)

No reasonable person would dispute the claim that objects have no business in code where performance is essential. I suspect that you'd agree with me here. That it's absurd to add objects to a language for no reason other than OO was the hot buzzword at the time (clearly ignoring all the research!) should be just as certain.

I would argue that properly used classes and objects will improve your program in several dimensions.

You wouldn't be alone, though that isn't a claim you'll find substantiated by the literature. (Though I've seen it inexplicably asserted a few times -- of course, the ACM is loaded with sloppy scholarship, as I'm sure you are all too painfully aware.)

I would strongly disagree with the claim as, in my experience, objects tend to be misused (in place of records, in place of proper modules, in place of libraries, in place of ...) and OO techniques tend to result in unnecessary complexity, unnecessary dependencies, bloat the code base ... I could go on.

Yes, I see the "properly used" qualifier, but you'll find that there's no general agreement about that either.

I'm glad I'm not still in the trenches.

Re:What?

[Samantha Wright]

Actually, the Currency datatype provides a fixed decimal. It was removed in VB.NET for no clear reason, but provided a 64-bit value with a constant 4 base 10 digits in the fraction.

And I believe the official abbreviation is "PL/I". :)

Re:What?

[Samantha Wright]

PHP is cheating! However, you may like this.

Re:What?

[real-modo]

Index-oriented access is actually a very restrictive way of accessing large data sets and CS professionals should break out of the jail called "relational database". Not every lose part requires fixing by nail.

??? One uses an RDBMS when one wants ACIDity. If you're reading the full contents of a table directly from an RDBMS and performance is important, of course you're doing it wrong.

In my experience, though, the problem is the reverse. Most CS professsionals don't understand the purpose or capabilities of RDBMSs (although they think they do: heavyweight key-value stores, yeah?), and avoid using them. Instead, they re-implement a limited, buggy, and badly designed subset of RDBMS's capabilities in their apps -- or just say things like "there won't be a lost update, there won't be races, there won't be system failures."

Re:What?

[Nutria]

You know I never understood the hate for COBOL

In 1984 it was:
1) Comp Sci snobbery.
2) Horrible textbooks.

The painful contortions that Shelly & Cashman twisted COBOL-74 into so as to be GOTO-less meant that no one liked the language.

It was only when I got a Real Job in the Real World that I appreciated the power of COBOL.

Re:What?

[flyingfsck]

COBOL is heading to the Cloud and will get 72 virgins...

Re:What?

[cyber-vandal]

The cloud is just the 21st century rehashing mainframe concepts so why not use COBOL for it?

Re:What?

[gauss72]

Tell that to the armies of OLAP developers/analysts. They believe their RBBMS nail will answer all analytics questions. Just recently they have rediscovered batch-mode analytics and call it MapReduce. See TeraData Aster. How do you need ACID for a read-only database ???

Re:What?

[gauss72]

Typo: must read "RDBMS"

Re:What?

[gauss72]

I think you meant "Cobol programmers are on average 72 year old, bearded virgins" ?

Re:What?

[MrMr]

Exactly, Algol60 was the language that targeted Die-kstra. Seemed to have missed him though.

Re:What?

[serviscope_minor]

I've heard there are disgusting perverts on the internet, but I never believed it until I saw this post. To even think of such foulness you must be deeply disturbed.

Re:What?

[RabidReindeer]

I think that's sort of the appeal of combining COBOL and Java in one server product. Now, PHBs can use Java for record-oriented applications and COBOL for everything else. Prior to that, they'd have to pick one or the other.

How does COBOL stack up against classic VB for record handling? Or older BASICs for that matter? The BASIC family is generally held to be pretty good in that department.

Having fought mainframe-style records in DB/2 in Java, what I wonder is how they are managing the fundamental data format issues.

COBOL didn't support variable-length strings for ages. The optimal record in COBOL consisted of fixed-length fields.

Java, on the other hand, can only support fixed-length character strings (semi-)properly when they are done as character arrays, and they didn't spend excessive amounts of time making character-array manipulation as easy as fixed-length string handling is in COBOL.

DB/2 just makes it worse, since the stock JDBC driver (and perhaps DB/2 itself) have a bad habit of returning space-padded fixed-length fields as space-trimmed character string objects when used with popular ORM systems, causing all sorts of hair-tearing issues when two "identical" items are compared and one of them is padded but the other isn't. Cache lookups, table joins, and all sorts of other critical operations fail for no obvious reason.

Re:What?

[Hognoxious]

Oh come on, DNA is nothing like XML.

Some people can understand DNA...

Re:What?

[Hognoxious]

In the mid 90's, when I had to use the darn thing, it was primitive control structures, no variable scope (OK, one) and general verbosity.

Though in fairness it was an old implementation, plus the coding standards there were peculiar and zealously enforced, so it's possible that they didn't even teach us the alternatives.

Re:What?

[Nutria]

No doubt that COBOL can easily be made very painful.

Maybe I was just fortunate to hook up with grey-beards who *grokked* the language far more than our textbook and teacher ever did, and showed me language features and coding techniques that made the programs quite structured.

Re:What?

[Samantha Wright]

Fortunately, all of the data formats for storing nucleotide information were standardized before XML became popular. It's mostly newer topics of computational interest, like metabolic networks, that suffer. (Although I'm sure there's one or two obscure proprietary formats that put raw gene sequences in XML anyway.) You can feel the generational gap as intelligent, record-oriented formats give way to ugly lazy ones, although not all new formats are stupid... and some formats could honestly be called attempts to re-invent XML, like ASN.1, which NCBI offers (although I don't know of anything that actually reads it.)

Re:What?

[Hognoxious]

Had to laugh at the is_a thread. Undeprecated, Dedeprecated[1], reprecated? Or just precated?

[1] this has the advantage that if you change your mind again you can dededeprecate it and after that [that's enough - Ed].

Re:What?

[Hognoxious]

IIRC it doesn't have functions at all. And having seen code where blocks of code[1] were copy-pasted dozens of times with the variables manually changed (sometimes) a typical business report certainly could make use of them.

[1] to add insult to injury, in a language that did support them.

Re:What?

[Nutria]

While COBOL doesn't have functions that reside in the same file as the code you're currently writing, it certainly does (since at least COBOL-74) have CALL. Actually, though, those are procedures.

A lazy programmer is a lazy programmer no matter what language he uses.

Re:What?

[Hognoxious]

Even if I'd known about those features, I would have been taken out and shot for using them. As I said, bizarre coding standards, rigidly enforced.

There was something terribly clunky about arrays. I remember writing an EDI converter. Because the order of the incoming records doesn't correspond to that of the outgoing ones, and they don't correspond 1:1, you need a lot of arrays to park stuff until you have a whole transaction to cut, shut & put. Except either it didn't have arrays, or we weren't allowed to use them. Nightmare.

This is 20 odd years ago, so time plus the natural tendency of the mind to protect itself might have obscured some details.

Re:What?

[hairyfeet]

But isn't that true of ANY language? I mean you name the language and I could find bad examples of code done in it, again its not the language's fault, its the coder. I have seen beautiful VB and I've seen piss awful C++, doesn't make one better than another, just meant the one writing in VB was better than the coder writing in C++.

But again it all comes down to using the right tool for the job, Java seems to work well on server backends, COBOL works well on mainframes, VB was good for GUIs for local DBs, as long as you don't try to force it to do a job its not good at I really don't see the problem.

Re:What?

[KZigurs]

You forgot that the frontend is driven by RubyOnRails. In a Cloud.

Re:What?

[Samantha Wright]

Admittedly I haven't had the pleasure of fixed-length strings in Java (not a lot of that in my line of work), but what you're saying sounds... predictable enough. That's why I suggested BASIC; it actually does have fixed-length strings (most notably in structs, which it calls Types, confusingly) which work with the same functions as its regular variable-length strings.

Re:What?

[Samantha Wright]

"Deprecated" in PHP jargon means "widely used."

Re:What?

[Nutria]

Most people aren't as open-minded as you...

One correction, though: mainframes *are* back ends. And COBOL is a very portable language. As long as you aren't calling CICS or IMS, mainframe code should run perfectly fine on Linux.

Re:What?

[david_thornley]

Some of us have used COBOL and escaped to saner languages (like C++ and Perl - and I'm not being ironic). What I mostly missed in COBOL last I used it was functions, but there was a lot of competition. COBOL may be better now, but I may never know.

I figure that if I've used something for more than a decade, I have a right to hate it.

Re:What?

[david_thornley]

A function is something I can stick into an expression and keep going. A subroutine or procedure is something I need to stick as its own statement and pick out the return values. They aren't the same thing.

Re:What?

[Nutria]

They aren't the same thing.

Which is why I wrote, Actually, though, those are procedures.

Re:What?

[Anonymous Coward]

Where I worked the gap was bridged with PERL

Re:What?

[jd2112]

I've worked in IT for over 20 years, inducing several years working for a major financial institution. After all I've seen Microsoft and Apple just don't seem that evil to me anymore.

Re:What?

[hairyfeet]

Well anybody who has followed me here knows I'm quick to call out bullshit where i see it and saying "X is bad" because X can be used badly while ignoring that A-Z can likewise be made to run piss poor code? Bullshit.

And maybe I should have made myself more clear, when i think of server backends i think of one or more X86 units doing the job whereas the big iron is a completely different story. Sure it CAN be used as a generic server backend but considering how much those suckers cost that wouldn't be the brightest thing to do, last article i saw said the biggest growth for the mainframe were in these huge MMOs and military simulations, jobs where you would need such a huge pile of X86 units it just wouldn't be practical.

And this is why people choose IBM

[phantomfive]

IBM is more expensive, but you can be sure they have more commitment to backwards compatibility than anyone else. If you build on the right IBM technologies, you can be sure your code will be working 30 years from now. No need to rewrite ever few years with the latest fad.

Re:And this is why people choose IBM

[DarkOx]

Agree, never my snarky post higher up in this discussion. The fact is COBOL is proven to scale and does the things its really good at; probably better than anything else. IBM mainframe MVS platforms are probably the best damn environment to run it in to with the longest stretch of forward and backward compatibility to maximize your software development investment. Generally the calls to kill off COBOL come from the ignorant.

Re:And this is why people choose IBM

[Anonymous Coward]

But throwing out mature and stable technologies for the fad of the week is what we are told is what a good programmer is supposed to do. Using "old" technology means you're a stagnant fossil.

Re:And this is why people choose IBM

[exabrial]

COBOL is basically assembly... very easy to compile to efficient code.


However I disagree that COBOL scales cheaply or efficiently. You could practically build a datacenter for the price of IBM's mainframes.

Re:And this is why people choose IBM

[phantomfive]

Yeah, I sure wouldn't start a new project in COBOL, but rewriting a system just for the sake of rewriting is silly. If the COBOL is doing fine, then leave it in COBOL.

Re:And this is why people choose IBM

[Anonymous Coward]

But throwing out mature and stable technologies for the fad of the week is what we are told is what a good programmer is supposed to do. Using "old" technology means you're a stagnant fossil.

As time goes on those stangnat fossils as you call them are being paid more and more. And they're laughing all the way to the bank while the new generations writes 2 € fart apps for stupid smartphones.

Re:And this is why people choose IBM

[Anonymous Coward]

Yeah, I sure wouldn't start a new project in COBOL,

but rewriting a system just for the sake of rewriting is silly.

If the COBOL is doing fine, then leave it in COBOL.

Yeah, the fucking Gnometards should learn a lesson or two from IBM.

Re:And this is why people choose IBM

[Anonymous Coward]

Probably, but what's the cost look like when you factor in needing to rewrite the entire code base to run on the hardware at that datacenter?

Re:And this is why people choose IBM

[CaptainJeff]

However I disagree that COBOL scales cheaply or efficiently. You could practically build a datacenter for the price of IBM's mainframes.

True...assuming you don't already have an IBM mainframe.

Re:And this is why people choose IBM

[Anonymous Coward]

IBM is more expensive, but you can be sure they have more commitment to backwards compatibility than anyone else.

Which is why perfectly fine programs for the 360 crashed on the 370, because the ZAP instruction's semantics had changed?

Maybe they have more comittment today; they didn't 40 years ago.

Re:And this is why people choose IBM

[Anonymous Coward]

COBOL is basically assembly... very easy to compile to efficient code.

Rubbish! In fact a great deal of the performance problems with CISC machines was the extra instructions added for COBOL to reduce "the semantic gap" and allegedly make compilers more efficient (why? you only compile once)

When I worked on Honeywell mainframes we had instrctions that could take a binary (or packed decimal) number and format it for, e.g. printing on a check, complete with comma separators a decimal point and check protect asterisks. You could even specify the micro-ops for the formatting.

I'm betting that one instruction caused the cpu's clock speed to be much slower than without. All the pro-RISC arguments in fact.

COBOL is similar to assembler because it lacks native block structure and recursion.

Which isn't that similar.

Re:And this is why people choose IBM

[Anonymous Coward]

Datacentre? I'm virtualizing an IBM MVS mainframe on my Samsung Galaxy S3.

Re:And this is why people choose IBM

[Anonymous Coward]

IBM is more expensive, but you can be sure they have more commitment to backwards compatibility than anyone else. If you build on the right IBM technologies, you can be sure your code will be working 30 years from now. No need to rewrite ever few years with the latest fad.

As a bonus, the reps will even give you a reacharound when they hand you the seven-figure bill for another year of service...

Re:And this is why people choose IBM

[mendax]

Hogwash! COBOL only worked well on mainframes that had instruction sets that were designed for it. As an example of COBOL on a machine that was NOT designed for it I offer up the following. I learned COBOL on a Control Data Cyber 170-730 (yes, a successor to Seymour Cray's CDC 6000-series beasts from the 1960's). COBOL on this poor man's supercomputer was a dog and slow. But the university administration used this machine for many years and its database support was more than adequate for their needs.

Now, if you wanted to run FORTRAN programs on this beast that was a completely different story. Seymour Cray designed the CDC 6000-series machines specifically to allow the FORTRAN compiler to generate very efficient code.

Re: And this is why people choose IBM

[bws111]

Huh? The only thing that changed was what happened when an invalid sign digit was detected. In both cases a program check - data exception was raised, and the instruction counter in the old program psw pointed to the next sequential instruction. The difference was that in 360 the operation was terminated, and ln 370 it was suppressed. Terminated meant the state of the output operand and condition code were unpredictable. Supressed meant that the operand and condition code were the same as they were when the instruction started.

So, no âperfectly fineâ programs had to change because of this. However, some programmers who thought they were clever probably found out that âunpredictableâ meant âdo not rely on this behaviorâ. Perhaps you were one of them?

Re:And this is why people choose IBM

[Guy Harris]

Which is why perfectly fine programs for the 360 crashed on the 370, because the ZAP instruction's semantics had changed?

I.e., in S/370, invalid signs in decimal numbers suppressed, rather than terminating, the operation? (A change not unique to ZAP.)

Re:And this is why people choose IBM

[Anonymous Coward]

Someone either hasn't priced a datacenter (brown-lot price? $14M) or hasn't priced a zSeries machine (last quote I saw $1.4M). :)

Re:And this is why people choose IBM

[gauss72]

Yeah, you ran Women's stuff on a Man's computer.

Re:And this is why people choose IBM

[Anonymous Coward]

Have you seen the assembler code the IBM Cobol compiler puts out? Truly butt ugly and inefficient.

Re:And this is why people choose IBM

[Anonymous Coward]

haha I think you just figured out why it's a good idea to rewrite it using new technologies...

"at time does on those stagnant fossils as you call them are being paid more and more"

Re:And this is why people choose IBM

[gauss72]

Actually, my impression of IBM is that they deliver quite crappy technology on a regular basis, because "we can fix that later on". Cynical colleagues suggested this being a business strategy with the objective of selling support. At a former employer we discovered a broken integer division instruction. When demonstrated to the IBM field engineer, they finally agreed to fix it by means of a microcode update.
Just recently I fought with DB/2 and only the field engineer could help this time, again.
IBM was always very much sales/service oriented and they still cannot compete with the "shrink-wrapped" companies like MS and Oracle. IBM is a relic of the past and will soon be history because it is simply much more efficient to perfect a product once instead of sending a field engineer to each and every customer to clean up the problems they haven't fixed during R&D time.

Re:And this is why people choose IBM

[Anonymous Coward]

COBOL has a very rigid syntax and very strong and explicit data typing, both combined with a program source format which can be easily read and understood by accountants and other non-programmers. All of which make it much more difficult for a hot-shot programmer to massively screw the pooch in some convoluted way that nobody else can find or decipher. There is no "Obfuscated COBOL" competition.

This is a good thing in programs that do your accounting and print your checks.

While the syntax and data rigidity might make it less trying to write (and much more importantly, debug and verify) a COBOL compiler than a C++ compiler, they don't really have much to do with the scalability of the output code.

And, FYI, when you have a current IBM mainframe, you do have a datacenter.

Re:And this is why people choose IBM

[Anonymous Coward]

So much ignorance expressed in some many ways.

I've read your post several times and still can't decide how you've managed to decide that IBM (hardware and database) can't compete with Oracle (database and application software) or Microsoft (operating system and office productivity software) when they primarily operate in different domains.

Yes, Oracle does try to push Sun hardware but they won't push too hard if it might cause them to lose the database and application business. And IBM won't push too hard to sell their database and applications if it might lose them the hardware business. And Microsoft doesn't really compete against either of them in either area.

Oh, and IBM mainframe hardware is generally quite reliable stuff.

Re:And this is why people choose IBM

[Anonymous Coward]

COBOL is basically assembler? Yes, 'cause just the other day, I wrote:

        mov accumulator-register, base-pointer[base-address][scaled-offset] :-)

Re:And this is why people choose IBM

[Anonymous Coward]

I think you'll find that IBM fix their bugs for free. Well, free in the context of massive maintenance contracts but you're paying for those regardless.

And if you're stating that the shrink-wrapped products from MS (as one example) are complete and bug-free, what the F is Patch Tuesday and SPn?

Re:And this is why people choose IBM

[countach]

Bull. You can't be sure your code will work next week, IBM or not. You think the IBM websphere code I'm working on now is guaranteed in 30 years time to work? Never.

Re:And this is why people choose IBM

[phantomfive]

If you choose your technology right, there's a high probability it will be supported. I don't know enough about websphere, so I will trust your judgement on that topic.

But compare that to Apple's system, where absolutely no software compiled before 2005 will run on the current OSX.

Re:And this is why people choose IBM

[pipatron]

COBOL is similar to assembler because it lacks native block structure and recursion.

Which isn't that similar.

I've used recursion in assembler code plenty of times, not sure what you mean here.

Re:And this is why people choose IBM

[gauss72]

If they ever let me close to a Cobol system, I am sure it will be infested with macro-based generic data structures pretty soon. There is a need for a Cobol Standard Library (of my own invention), I am quite positive !

Re:And this is why people choose IBM

[gauss72]

The difference is that I can get the typical MS product running in a reasonable manner without the aid of an MS field engineer. For example, when DB/2 competes against SQL Server, developers will disregard DB/2 quite early when they can't get proper connect times without the help of the IBM field engineer. Maybe DB/2 is actually better than SQL Server on the long run, but there won't be a long run because initially it looks like a very bad product.

Re:And this is why people choose IBM

[gauss72]

Maybe you just read what I write: IBM delivers shoddy quality which must be fixed by their field engineers. MS does have their fair share of bugs, but they are definitely not as bad as IBM. So does Intel - their processors at least don't crap out on the integer operations.
IBM is a company dominated by the sales and finance guys. Technology is very much a nuisance to them, which they only need to make $$. At MS and Intel, there seem to be some technologists at the critical posts, even though the MBA-In-Chief of MS appears to "change" that, recently.

Re:And this is why people choose IBM

[gauss72]

As a qualifier, maybe the mainframe IBMers are especially shoddy. We never had these problems with their Power machines. These were actually excellent Unix machines - fast, reliable, very high quality. But DB/2 and mainframe, not so much. Thinking about it, maybe it indeed is a deliberate tactic to force customers into expensive support contracts.

Re:And this is why people choose IBM

[bws111]

It sounds to me like you are confusing incompetent admins with bad products. You absolutely do not need IBM service people to install DB2 and have it perform like you want.

A mainframe is not a PC. You can not just buy an off-the-shelf mainframe, load some software on it, and expect it to perform as you want. Every mainframe is built to customer order, and there are literally millions of possible configurations. This includes not only obvious stuff like how much memory and how many cores do you want, but workload-dependant stuff like what speed should the processors run at, how many cores are dedicated to running IO operations, how many to DB2 functions, how many to Java functions, etc. It is up to the customer to understand their workload and configure the machine appropriately.

Then, once the machine is installed, there is more configuration to be done (by the customer). You must create your IOCDS to properly balance your expected IO over all of the IO domains. You must dedicate enough channel paths to your busiest devices, etc.

So, it is no surpise that someone who does not know what they are doing can make an unholy mess of things and wind up with an extremely poor performing system. Yes, IBM will help you fix your mess. No, that does not mean IBM produced a shoddy product.
Then, you need to define your LPARs. What percentage of the resources does each LPAR get? Do the LPARs have caps on them, etc?

Re:And this is why people choose IBM

[evilviper]

IBM is more expensive, but you can be sure they have more commitment to backwards compatibility than anyone else.

Anywhere there's truck-loads of money to be had, SOMEBODY will jump-in and continue to provide compatible options, forever. See the NuVAX 3200 (DEC VAX compatible) servers for the US military weapons systems.

Even modern x86 CPUs will still run code compiled for those first 8008 CPUs.

And for IBM, you'll REALLY be paying through the nose... Paying ongoing fees just for the right to continue using your mainframe and software, even if you don't want support. And you'll know the joys of your system being based one EBCIDIC, where everything else today uses ASCII or better.

Re:And this is why people choose IBM

[phantomfive]

Very true, you need to do a cost-benefit analysis.

But come on, character encoding? How much worse than Microsoft's mbstowcs_s() and friends? I'm sure there's worse things to complain about than that.

Re:And this is why people choose IBM

[evilviper]

I just took the opportunity to throw-in one of my pet peeves. Even a simple text file needs to be converted to be readable anywhere else... Things that are absolutely trivial on every other platform, like FTP'ing a file, become complex, because of the need for character conversion... It's a constant annoyance.

Re:And this is why people choose IBM

[phantomfive]

That's weird, don't they have support for ascii or UTF-8 by now?

Re:And this is why people choose IBM

[evilviper]

Backwards compatibility means never adding new features such as this trendy new "ASCII" thingy...

Since plain text is so simple, there's no uniform header or similar, that the system can use to autodetect the contents and switch between the two transparently, so there's no easy way to support ASCII will staying EBCDIC compatible.

Of course my experience is only with a small sliver of IBM's product line (several mainframes). But a quick look at Wikipedia reports the following:

"All IBM mainframe and midrange peripherals and operating systems use EBCDIC as their inherent encoding,[3] but AIX running on the RS/6000 and its descendants including the IBM Power Systems, Linux running on the zSeries, and operating systems running on the IBM PC and its descendants use ASCII."

Some nice context in there as well:

"the EBCDIC alphabet is non-contiguous, interleaved with unassigned characters which may or may not be in use. Data portability is hindered by a lack of many symbols commonly used in programming and in network communications."

Re:And this is why people choose IBM

[Hognoxious]

Never seen a mainframe throw a BSOD. Well, it'd be a GSOD, but anyway...

Re:And this is why people choose IBM

[david_thornley]

When I did IBM assembly language programming in the mid-70s, there was a single instruction that would take a COBOL-style formatted record and a list of values, and turned the formatted record into a printable line. (Lots of places didn't spend the money on a compiler at that time, and ASM/BAL basically came with the machine.) I have never seen anything that CISCy before or since.

Re: And this is why people choose IBM

[david_thornley]

There was an emulator for an earlier computer (7090 series?) that ran on the 360. (IIRC, it had different microcode.) When working on it, the IBM engineers found numerous cases of undefined behavior that turned out to have predictable behavior on the 7090 and had to be replicated in the emulator. Brooks, in The Mythical Man-Month (aka What I Learned Making OS/360) said that the 360 idea of developing multiple models worked very well, as it meant that the instruction set had to stay the same (adapting it because one model team was finding it difficult would force all the others to change), and it probably also helped undefined behavior stay undefined.

Back then, the idea that programs would outlast individual computers hadn't quite caught on, and even now I see unpleasantly many people asking what "c += c++;" does in C. When I got interested in home computers in the late 70s, I'd see lists of "undocumented opcodes" for at least the Z80 processor.

Re:And this is why people choose IBM

[bws111]

Wrong. Backwards compatibilty means not breaking existing stuff. It has nothing to do with new features. And by the way, current mainframes have instructions for converting from one utf code (or unicode) to another.

Re:And this is why people choose IBM

[evilviper]

Try reading past the first sentence of my post, and get back to me with your clever plan to easily and transparently support both ASCII and EBCDIC format.

Re:And this is why people choose IBM

[bws111]

The rest of your post boils down to 'code page translation is hard'. No kidding. That has nothing to do with mainframes or backwards compatibility however. And what is harder about translating between ASCII and EBCDIC as compared to translating between the hundreds of ASCII variants (code pages) out there?

Rebranding

[Chaos1]

IBM should take to calling it Cloudframe. Because everything needs a cloud based marketing spin.

Re:Rebranding

[amiga3D]

Oooooh! Better register that trademark! Cloudframe. That even sounds like an IBM type of market speak.

Re:Rebranding

[funwithBSD]

You are lagging a little behind our market speak.

It would be CloudFlex or PureFrame.

Re:Rebranding

[game kid]

Don't you mean CloudFlxr, or pyUrFramely?

Re:Rebranding

[Anonymous Coward]

You do realize that "the cloud" is just a stupid re-branding of mainframes claiming to be commodity hardware? Yes, the processors and chassis are commodities, but the interconnects, cooling structures, and management architectures in "the cloud" are just scaled up supercomputer concepts with OO programming. The big difference is that now your thin clients do graphics in "apps" that are shells for HTML5, instead of VT terminals. Nothing here is very new, except for a few parts that are easier due to the cheapness of silicon 40 years later.

Re:Rebranding

[gauss72]

I don't think that you actually understand what you write. The CPUs are definitely not commodity, even if it would make sense to emulate the S/390 instruction set on x86 CPUs. Which it doesn't from a reliability/serviceability perspective. And "supercomputers" were the "men's" toys to simulate the weather and how to evaporate Russian cities, amongst other belligerent stuff. Mainframe != supercomputer. Mr Watson of IBM once tried to disprove that and got his fingers burned when he tried to compete with Seymour Cray. Actually, his little army of engineers got their fingers burnt when they competed against that single guy Cray.

Re:Rebranding

[Anonymous Coward]

Yes, and since that time Cray has become the overwhelmingly dominant force in the computer marketplace while the once-mighty IBM has faded into obscurity.

Re:Rebranding

[Anonymous Coward]

PHB did it first: http://www.dilbert.com/strips/comic/2012-10-21

Re:Rebranding

[gauss72]

Oh, yeah, score a point by making a different argument. Seymour Cray literally owned the supercomputer business (NSA, LLNL and that type of thing) until he died. Just recently IBM does some sort of supercomputing business again, but these are NOT mainframes. IBM supercomputing are massive clusters of Power CPUs. If Seymour Cray still lived, I am sure IBM would NOT be in supercomputing.

Re:Rebranding

[Anonymous Coward]

IBM should take to calling it Cloudframe. Because everything needs a cloud based marketing spin.

I cried when I read this. It's beautiful. Just as beautiful as ANYTHING.net, eANYTHING, or iANYTHING.

if it aint broke

[decora]

hook it up to javascript so that the 20 somethings fresh out of college can use it

Why?

[Viol8]

It does what it was designed to do - mega scale batch processing of flat files - fantastically well. Just because a language doesn't have curly brackets and the latest fad paradigm championed by vory Tower Academics Inc doesn't mean its day has passed.

For the record , no , I'm not a Cobol coder, but I'm old enough to know that when something works well in its sphere of operations its worth holding on to.

Re:Why?

[gauss72]

MapReduce is just the latest form of Batch Processing, with a fancy new name from the Googlers. So in 2005 Google discovered something IBM knew in 1955.

Re:Why?

[Anonymous Coward]

Ironic isn't it.... :-)

Re:Why?

[serviscope_minor]

vory[sic] Tower Academics Inc

Ah, it's chip-on-the-shoulder time again!

I like how, with your use of inc there even manage to blame most of the corporate driven computer language fads on "Ivory Tower Academics".

Well done.

Whippersnappers

[Anonymous Coward]

COBOL is for real men. I can see how it would scare off all the kids who don't know real computing before that newfangled MS-DOS.

Re:Whippersnappers

[ebno-10db]

COBOL is for real men. I can see how it would scare off all the kids who don't know real computing before that newfangled MS-DOS.

COBOL is for wimps. Real mean write machine code.

Re:Whippersnappers

[gauss72]

Well, men use FORTRAN. Real men are not beancounters, they work on some lethal machinery. Semi-real men like me at least use C++ to do beancounting, which they call "statistics".

Re:Whippersnappers

[Anonymous Coward]

Yeah well I already suggested to my colleagues that we should rewrite this here refinery control system in Fortran instead of C++, but they were strangely reluctant..

COBOL code is not too different

[plopez]

from much of the code I have seen written in Java, C#, Python, or Perl. Heck, VB was based Basic which drew on COBOL and Fortran, since it was a teaching language and so it had much of the syntax and idioms of those languages. Anytime you use VB your are using a form of COBOL.

BTW if you want to check out something cool, check out Fortran 2008. It supports the OO paradigm, has built in parallel processing support, and is backward compatible to Fortran 77. It's not dying anytime soon either.

Re:COBOL code is not too different

[93 Escort Wagon]

Anytime you use VB your are using a form of COBOL.

Anytime you use Visual Basic, you are incrementing the counter keeping track of exactly which Circle of Hell you'll eventually be deposited into.

Re:COBOL code is not too different

[Horshu]

COBOL is massively different from the C family of languages, even with the OO added to it. And as for Fortran, it may be alive and well, but try replacing a Fortran job once you lose it.

Re:COBOL code is not too different

[Anonymous Coward]

Anytime you use VB your are using a form of COBOL.

Anytime you use Visual Basic, you are incrementing the counter keeping track of exactly which Circle of Hell you'll eventually be deposited into.

Phew, luckily I dont believe in hell, so its allll good

Re:COBOL code is not too different

[mendax]

Some day the Twelve Coding Tribes are going to going to leave their worlds in search of the Lost Planet of the Gods, COBOL. (Whoops, wrong universe [and spelling].)

Re:COBOL code is not too different

[Howitzer86]

This only works if you're a bending unit.

Re:COBOL code is not too different

[93 Escort Wagon]

Or a Series 4000 mechanoid.

Re:COBOL code is not too different

[excelsior_gr]

The OO paradigm has been supported since Fortran 90, albeit somewhat primitively. Dying? I finished writing my latest Fortran program last week!

Concerning backwards compatibility though, there are some features of Fortran 77 that have been deleted in the latest versions. Not anything that anyone will (or should, for that matter) miss, since I am talking about very archaic features here. I am sure that compilers will still support them though.

Also, kudos to the gfortran people for the good work on the compiler, if anyone is reading this. I have been keeping an eye on the progress and it was dramatic in the last years. Also, the g95 compiler looked dead and I thought that Andy gave up, but now I see an update made on the source in Jan 2013 after 2.5 years. Can someone share an insight?

Re:COBOL code is not too different

[excelsior_gr]

but try replacing a Fortran job once you lose it.

A good programmer can write Fortran code in any language.

Re:COBOL code is not too different

[gauss72]

Most importantly, read the papers of David Kuck. A MUST for your professional development as a Computer Science graduate who wants to continue to work in this field (as opposed to doing "business" things). http://www.computer.org/portal/web/awards/pioneer-kuck http://www.dtjcd.vmsresource.org.uk/pdfs/dtj_v06-03_1994.pdf

Re:COBOL code is not too different

[gauss72]

Sorry for messed-up formatting.

Re:COBOL code is not too different

[plopez]

Basically what I mean is that the use of OO is primitive in the code I was speaking of. The code monkey was writing code which could have been done, sometimes better, using COBOL. The flexibility and extensibility of an OO paradigm was lost to the programmer.

Re:COBOL code is not too different

[Anonymous Coward]

It's OK. Just be a bit more careful next time. Have a nice week!

Re:COBOL code is not too different

[gauss72]

Muharg. In Java you can't have arrays of structs. You can have an array of references which points to your 25 million individually allocated heap objects. Which is both a runtime and a massive storage overhead. Plus, it destroys your cache efficiency.
So, get off my lawn and stop saying stupid things in the presence of grown-ups !

Re:COBOL code is not too different

[excelsior_gr]

This is why I program in Fortran. Who said anything about Java? A Fortran programmer won't touch an interpreted language with a 30-foot pole. Are you even replying to the correct post?
Now get outta my sight before I unleash the dogs!

Kill it!

[Alejux]

Kill it with fire!!!

Re:Kill it!

[iggymanz]

I agree, Java / EE is just warmed over c++ and makes for the most bloated set of pigware known to man.

Let's not weigh the mature base of COBOL apps that is moving our money and processing our insurance claims with that rubbish

Re:Kill it!

[Anonymous Coward]

Says somebody completely ignorant of Java EE....

Re:Kill it!

[iggymanz]

hardly, have the misfortune of working with weblogic, tc server and websphere for over a decade

Cobol Analist

[Anonymous Coward]

In Brazil, a Cobol Senior Analist have a average $174k anual. I guess that tech goes more 30 years, yet. IBM have a lot of money for sake Cobol, so why give up? There is no problem when a lot of profit in revenue in legacy technology comes easy, stable, sure, and right. Money, please welcome!!!

Re:Cobol Analist

[Anonymous Coward]

COBOL analist? Does this person fuck someone in the ass while programming?

Re:Cobol Analist

[Anonymous Coward]

In Soviet Russia, COBOL fucks YOU!

PROGRAMID. Harakiri.

[Anonymous Coward]

MOVE secretbankinfo TO publiccloud DISPLAY Destroying myself now. Bye bye COBOL.

COBOL is just fine thank you

[Anonymous Coward]

Keep things as it is, as there is a reason that its rock solid. Don't screw with it like this and destroy it.

Obligatory

[Anonymous Coward]

http://www.coboloncogs.org/

Have any of the people griping USED COBOL?

[khb]

The 2002 version of the standard added object features. While not my first choice of languages, it is typically not cheaper nor safer to rewrite large amounts of working tested code. Yes, you might do better with a clean sheet of paper and a decade or so, but most IT organizations don't have that luxury.

My favorite COBOL nerdy feature died many versions of the Standard ago (MOVE CORRESPONDING). It was my favorite not because it was a terrific feature, but it was just so unique to COBOL.

Cloud computing is, as a business model, a return to mainframe timesharing services such as dominated in the original COBOL and PL/I eras. It really is not a stretch to see IBM update their zSeries environment to easily enable leveraging the COBOL code base.

Yes, you can (and more cheaply per IBM MIP) run Linux on your zSeries hardware, so you can mix and match (write new applications, or layers in newer environments) ... but there is no need to toss out dull boring functional code that just happens to be business critical.

No doubt the sufficiently intrepid IT staffer could rewrite all the COBOL in Haskell or Perl .. (or for extra credit in REXX) but would it really be an improvement? Indeed, just validating that the new code is logically equivalent to the original code for ALL input sets would be a huge investment ... never underestimate the cost (or importance) of Test and Validation.

Re:Have any of the people griping USED COBOL?

[mendax]

I have, many years ago and only in school. My favorite COBOL statement I never used (was warned by professors NEVER, EVER to use) was ALTER X TO PROCEED TO Y. Code modification anyone?

Re:Have any of the people griping USED COBOL?

[BlindRobin]

I cut my COBOL teeth rewriting a market research analysis system written by a contractor that made extensive use of the ALTER statement expressly to obfuscate the code and insure that he was employed long term to maintain the code. The boss chose to call his bluff and I got he job of undoing the mess. Success meant my move out of operations and into a cube as a 'Junior Programmer Analyst'. 1974 was an interesting year.

Re:Have any of the people griping USED COBOL?

[Anonymous Coward]

My all time favorite statement was GO TO DEPENDING ON, took the value of the host variable and did a GOTO to the branch listed in the series below.

Re:Have any of the people griping USED COBOL?

[Anonymous Coward]

That's nothing. Wait until you see the COMEFROM instruction :-) You thought GOTO was bad, COMEFROM is GOTO on steroids.

Re:Have any of the people griping USED COBOL?

[Anonymous Coward]

> My favorite COBOL nerdy feature died many versions of the Standard ago (MOVE CORRESPONDING).

No it didn't. It is still in 2002.

Re:Have any of the people griping USED COBOL?

[gauss72]

One of the wisdoms I got from my education at HP Germany was "quality is tested into hardware". And with any real software, it is exactly the same. Or maybe should I say "even worse" ? The biggest investment is always testing, bug fixing, validation programs, test vectors, test vector generators, code reviews and so on. Initially the HP MPE operating system was very unreliable, but decades of bug fixing and refining made it into one of the most reliable operating systems.

Re:Have any of the people griping USED COBOL?

[baegucb]

Dang that brings back memories. MPEX was the 3rd or 4th OS I learned. That was back in the early 80s. But the IBM OS's even now have their roots back into at least the 70s, and it's still applicable now.
I learned COBOL back in the 70s as the second language I learned, after BASIC. If I wanted to, I could probably still get a decent job doing COBOL now, I would think. Some things don't change enough for it to matter. But I wouldn't want to do COBOL. I always considered it boring after learning assembler.

Re:Have any of the people griping USED COBOL?

[umghhh]

surely it can be written first time right so what is the point of testing except to pay for expensive testers?

Re:Have any of the people griping USED COBOL?

[Visserau]

COMEFROM

If thats anything what it sounds like, I'm genuinely terrified. There's no way I'm googling that.

Re:Have any of the people griping USED COBOL?

[Anonymous Coward]

My favorite COBOL nerdy feature died many versions of the Standard ago (MOVE CORRESPONDING). It was my favorite not because it was a terrific feature, but it was just so unique to COBOL.

ABAP has it too, which I suppose is normal considering it's a COBOL descendant. A somewhat interesting language, but the SAP environment it's ugly beyond belief.

Card reader

[Anonymous Coward]

BTW if you want to check out something cool, check out Fortran 2008. It supports the OO paradigm, has built in parallel processing support, and is backward compatible to Fortran 77. It's not dying anytime soon either.

But, I don't have a punched card reader anymore so how can I program in it?!

Cue Lords of Cobol references in...

[davidwr]

... 3, 2, wait, wrong spelling, nevermind.

The enhanced utility of Fortran

[goombah99]

Ironically the utility of fortran has only grown with time. Modern fortrans embrace parallel computing by having constructs that are inherently parallel; for example loops which announce they are parallel and can be done out of order and matrix operations as language primitives. One great innovation is the combination of python and fortran. You do things with precisely defined memory boundaries that are compiled to maximum efficiency using the simple clean fortran, and you do the messy stuff of memory allocations and references and exotic libraries and user interfaces in the python. No need to extend the fortran language and make is slower-- just put the non-speed critical stuff in the python part. With the rise of GPUs and their rigidly defined memory limits fortran is a nice fit. You actually want a constrained language for that. It's really an ideal combination. Fortran compiles so fast its even possible to have python write the fortran on the fly and then call it.

Re:The enhanced utility of Fortran

[ron_ivi]

One great innovation is the combination of python and fortran.

Huge agreement here!

I advocated the same Ruby/Fortran synergy back in 2006, with a working example:

http://marc.info/?l=ruby-talk&m=115619337609191&w=2

Completely agree that this is a great way to use the best tool for the job. I'd go so far as to claim that Python(or Ruby)-with-Fortran is a better tool for most jobs than C#-for-everything, which is kinda mediocre at all tasks..

So all the VBA programming in my masters program?

[Anonymous Coward]

Was deployed most of the time while getting a masters in math at TAMU and, well, VBA is the only programming language available on the Air Force's standard software load. I'm clearly going to hell.

Not Entirely Correct

[gauss72]

The term is "loop reordering". Essentially, you can iterate matrices row-wise or column-wise. If your matrix is stored row-wise, you better iterate it row-wise, or your cache locality will be very bad. Typical use case is matrix multiplication and solving linear equation systems. So that Mr Kuck of the uni of Illinois (now at Intel, still working !) created optimizing compilers which can do impressive things, including estimating how long a typical Fortran program run will take (surely that does not work for all categories of Fortran programs). In addition to that Mr Kuck developed compilers which would automatically exploit parallelism of "vector" hardware like the machines designed by Seymour Cray. Note that there is no need to explicitly say "parallelize this loop" as you need to do with OpenMP; the compiler can figure that itself ! Again, this proves that new != better. Fortran still beats C++ in numerical processing and that is quite interesting, considering the fact that Fortran is one of the very first programming languages ! Google Mr Kuck and his papers regarding Fortran compilers - it's an impressive part of computer science from the CDC6600 to the present day !

COBOL: Cloud Oriented Business Objective Language?

[non-e-moose]

Change the acronym, now relevant to OO-fans.

Very Disingenious

[gauss72]

I am now at the middle of my life expectation and growing a bit smarter. And, I talk to a Cobol programmer then and now in the bus home. He works for an insurance company and will probably retire as a Cobol programmer for that company. He is a mathematician and I am a CS guy; I know much more than he about algorithms, C++, templates, macros, databases and whatnot.
But just recently I realized that Map-Reduce and "record-oriented processing" are actually very similar in that they do NOT consume voracious amounts of main memory. Both perform full-table-scans, in database parlance, which has unique advantages over index-based access for many scenarios.
That's all important if your data set is 100 times larger than your main memory. So the mainframers have that capability since 1955 and the C++ guys just discover this in the year 2005 or so ??
Cobol is here to stay for very systematic reasons very few people understand, including those with a CS degree and those developing in Cobol for a very long time. The latter do Cobol simply because it always paid nicely and there is absolutely no end in sight.

Re:Very Disingenious

[serviscope_minor]

So the mainframers have that capability since 1955 and the C++ guys just discover this in the year 2005 or so ??

Not sure I follow. The C++ library I/O model has been around since the beginning. It's always been a stream based model, not a "load the whole file and then process it" model. It's basically an improvement over the similar but (for no good reason[1]) less flexible C stdio model.

The latter, coming from C, was designed specifically by people who liked pipes: the model has always been good for trogging through large files without having to read the entire thing into memory.

[1] The C++ iostream model allows one to replace the underlying streambuf object so a stream can refer to any data source easily. For some a similar facility is not present in stdio, though glibc shows it is perfectly possible. I never understood why this was not possible in C. It also produced the annoyance that so many libraries doing I/O had to provide their own structures providing such behaviour. So much work (and double buffering) would have been saved had the committee provided it.

what is cobol?

[Anonymous Coward]

cobol? never heard of it. I don't think the local university offers classes in it. ok, i'm showing my age. lol

had to use google to find out what cobol is: http://en.wikipedia.org/wiki/COBOL_%28disambiguation%29

Re:what is cobol?

[mendax]

You must still be in diapers.

We can...

[Virtucon]

Nuke it from orbit. It's the only way to be sure.

Re:We can...

[Lorens]

Nuke it from orbit. It's the only way to be sure.

You sure about that? I hate to be the one to break this to you, but the people using COBOL are the same people who pay insane amounts of money for a backup site thousands of miles away and offsite backups in nuke-proof shelters. If you want to get rid of COBOL, make something better. A nuke certainly won't do it.

Re:We can...

[Virtucon]

Well maybe "World War Z" should have been about COBOL and COBOL programmers then?

A zombie Grace Hopper running around would be funny... "nanosecond.. nanosecond.."

Re:We can...

[Anonymous Coward]

As they know perfectly well (it seems to be true that human stupidity has no limits), they can not be broken from the outside until broken from the inside. It is a shame that the assassin instict is not something they teach you at school (at least not in a more or less catholic country), because I was inside, and I could have striken a death blow for the C(yclones:-). If I remember properly, C is the only computer language invented by an engineer, so as a Computer Scientist I should have probably done it.

Cute subject

[Anonymous Coward]

OP has clearly missed the last 10 years of Linux on System z development and progress. Otherwise, he would not have thought that this was big iron's first foray into "the Cloud". Linux has been running here for over a decade, with WebSphere showing up as one of the first IBM products ported to the platform. Yes, 10 years. So have your fun. Just know that you come across as a little wet behind the ears in terms of enterprise technology.

You really don't know what you're talking about

[Anonymous Coward]

The reason that COBOL was slower than FORTRAN on CDC machines was the result of the superior code generating efficency of the FORTRAN compiler and some fine floating-point hardware.

CDC mainly targeted users who had floating-point compute-intensive applications (the scientific and engineering crowd) and provided a COBOL compiler so that those target users could say to their bean counters "yes, and you can use the hardware, too".

IBM, on the other hand, was targeting business users who had I/O-intensive applications and who really wanted the reliable multiple digit accuracy of integer math, not the "pretty good until you get to 17th decimal digit" accuracy of floating point. So there was high emphasis on COBOL performance and not so much on FORTRAN performance.

Both companies knew their target audiences and spent time and money on compiler optimization where it made the most sense.

Re:You really don't know what you're talking about

[gauss72]

Not entirely correct. Thomas Watson once decided to take out CDC and build a supercomputer. IBM would badmouth CDC "in support of our future machine". It turned out the single guy Seymour Cray beat the crap out of the army of IBM engineers.
Mr Watson was pissed but from then on focused on mainframes, not supercomputers.
Always good to see that a single capable and determined man can stand up to the sleazy multi-billion corporations and win !

How pervasive?

[CypherOz]

Factoids... "200 Billion lines of COBOL code in existence" eWeek "5 Billion lines of COBOL code added yearly" Bill Ulrich, TSG Inc. "Between 850K and 1.3 Million COBOL developers" IDC "Majority of customer data still on mainframes" Computerworld "Replacement costs $20 Trillion" eWeek Researchers at Aberdeen Group recently found that about 70% of the world's business data is still processed by mainframe applications written in Cobol. According to Gartner Group, that number is closer to 75%. "Although most people are blissfully unaware of CICS, they probably make use of it several times a week, for almost every commercial electronic transaction they make. In the whole scheme of things, CICS is *much* more important the Microsoft Windows." Martin Cambell-Kelly, "From Airline Reservations to Sonic Hedgehog" (a History of the Software Industry), MIT Press 2003 COBAL is not dead and won't die :)

4GLs - language of choice, sometimes

[Kittenman]

I'm aware of two 4GLs that themselves write code in COBOL - so you'd write the code in LDL+, and press a button/turn a handle and it spits out COBOL (and ALGOL, and C I think... who cares). It's rare when us folk used to get down to the COBOL level.

Re:4GLs - language of choice, sometimes

[Anonymous Coward]

The only 4GL I have had contact with is CA Gen. While yes you just turn the handle and out pours working Cobol/C/C#, I think it would be damn hard for any developer to churn out worse code than the shit those 4GL's generate (assuming the others have similar quality to the CA product). The cobol is atrocious, the C makes you want to cry and I can only guess that the C# would make you want to slit your wrists (have not tried that as a target though). It is a sad state that these 4GL's have gotten popular, the amount of wasted compute cycles is too scary to think about.

Support COBOL for our elder's jobs

[manu0601]

This is good news. After EU insane move to push retirement age in member countries, a well-alive COBOL market will means that some elder will actually be employed. Now we just need to find a solution for all the unlucky that cannot enjoy that.

Open Closed Principle

[ssufficool]

You can keep your COBOL code closed for modification and OPEN for extension using the cloud services model. Then more recent languages can extend the tested and proven COBOL business layer through web services. COBOL can rest comfortably behind the scenes without one bit of modification save a rare bug fix.

COBOL ?

[Anonymous Coward]

COBOL you say ? Hooray my skillz are still relevant :)

COBOL is the mainframe glue language!

[Anonymous Coward]

If you don't know mainframes, COBOL is the glue language. Every IBM product has COBOL bindings that makes it really, really easy to use them from a COBOL program. 10x easier than, say, C or C++. If you want to use DB2, CICS, IMS, MQ, and all the other IBM products, then COBOL is a good choice. COBOL is like Java or VB in the sense that it's harder to shoot yourself in the foot than it is in assembler or C. So COBOL has evolved into a niche of being the go-to mainframe language. As long as people need mainframes, COBOL will be around.

But - be really wary of "COBOL" jobs. No one wants a COBOL programmer. COBOL is easy to learn, but no one wants a programmer who only knows COBOL. They want people who know DB2, CICS, and all the others, and COBOL is the glue language you need to know. So when you see the yearly "we need more COBOL programmers" article, that's not the whole story.

We're doomed.

[dlingman]

http://landofthefreeish.com/code/the-terminator-was-written-in-cobol/

Cobol in the cloud - Sounds like Skynet to me...

In Related News ...

[jasnw]

Keuffel and Esser (K+E) have just announced their new electronic, cloud-accessible slide rule. Made of recycled circuit boards and faced with titanium recycled from old Soviet submarines, these babies can do just about anything with at least three-digit accuracy. Give-or-take a power of 10.

system/z runs all common web platforms

[iggymanz]

System/Z can run Linux, or various web platforms on the several common mainframe OS. you could have all kinds of so-called "cloud" computing on a mainframe with no COBOL in sight

Re:COBOL: Cloud Oriented Business Objective Langua

[Anonymous Coward]

Make that COBOL: Cloud Oriented Business Objectionable Language.

Net error delta: +1

[Hognoxious]

at time does on

And I just figured out why it's *not* a good idea.

Klingon my

[Hognoxious]

everything else today uses ASCII or better.

There isn't anything better than ASCII. If it was good enough for Ovid, Jesus Christ, and Shakespeare it's good enough for the likes of you.