Beta
×

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!

IBM Takes System/z To the Cloud With COBOL Update

timothy posted about a year ago | from the spirits-of-the-ancient-ones dept.

IBM 256

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."

cancel ×

256 comments

Sorry! There are no comments related to the filter you selected.

Anyone? (5, Funny)

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

A stake and garlic? Anyone?

Re:Anyone? (5, Funny)

Freddybear (1805256) | about a year ago | (#43769205)

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

Re:Anyone? (0)

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

Call Hellboy.

Re:Anyone? (0, Redundant)

iggymanz (596061) | about a year ago | (#43769425)

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? (4, Funny)

93 Escort Wagon (326346) | about a year ago | (#43769441)

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? (3, Funny)

ebno-10db (1459097) | about a year ago | (#43769523)

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? (4, Funny)

Aighearach (97333) | about a year ago | (#43769429)


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

Re:Anyone? (0)

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

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

Re:Anyone? (0)

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

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

Re:Anyone? (4, Interesting)

JPLemme (106723) | about a year ago | (#43769805)

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.

The enhanced utility of Fortran (3, Informative)

goombah99 (560566) | about a year ago | (#43769795)

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.

Not Entirely Correct (2)

gauss72 (2927137) | about a year ago | (#43769957)

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 !

Re:Anyone? (3, Insightful)

non-e-moose (994576) | about a year ago | (#43769983)

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

Re:Anyone? (0)

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

Don't forget the holy water!

Ugh (5, Funny)

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

Extended COBOL lifespan?!

THANKS OBAMA! :(

Re:Ugh (5, Funny)

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

Never a death panel when you need one.

Re:Ugh (4, Funny)

ColdWetDog (752185) | about a year ago | (#43769277)

The damned thing's immortal.

IBM has found the secret to everlasting life!

Surely, there is some money to be made here?

Re:Ugh (3)

PolygamousRanchKid (1290638) | about a year ago | (#43769345)

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 (5, Interesting)

ebno-10db (1459097) | about a year ago | (#43769575)

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 (2)

jd2112 (1535857) | about a year ago | (#43769603)

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 (2)

ColdWetDog (752185) | about a year ago | (#43769823)

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 (0)

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

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.

What? (2)

lord_mike (567148) | about a year ago | (#43769181)

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.

if it aint broke (3, Funny)

decora (1710862) | about a year ago | (#43769211)

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

Re:What? (1)

Samantha Wright (1324923) | about a year ago | (#43769217)

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? (1)

phantomfive (622387) | about a year ago | (#43769303)

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? (2)

Milvuss (1417689) | about a year ago | (#43769337)

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? (1)

Samantha Wright (1324923) | about a year ago | (#43769469)

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? (1)

phantomfive (622387) | about a year ago | (#43769543)

biology does involve a lot of Java and XML.

That is fascinating.

Re:What? (1)

Samantha Wright (1324923) | about a year ago | (#43769569)

Oh, how I wish it were.

Re:What? (1)

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

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? (1)

Samantha Wright (1324923) | about a year ago | (#43769489)

...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? (1)

Nutria (679911) | about a year ago | (#43769849)

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? (1)

Samantha Wright (1324923) | about a year ago | (#43769935)

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? (1)

Aighearach (97333) | about a year ago | (#43769451)

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

Re:What? (2)

jd2112 (1535857) | about a year ago | (#43769627)

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? (4, Insightful)

Freddybear (1805256) | about a year ago | (#43769235)

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? (0)

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

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

In what way, pray tell?

Re:What? (2)

Freddybear (1805256) | about a year ago | (#43769477)

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? (2)

narcc (412956) | about a year ago | (#43769557)

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? (1)

gauss72 (2927137) | about a year ago | (#43770025)

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? (2)

Nutria (679911) | about a year ago | (#43769867)

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? (0)

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

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.

Why? (1)

Viol8 (599362) | about a year ago | (#43769245)

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? (1)

gauss72 (2927137) | about a year ago | (#43770041)

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:What? (1)

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

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? (0)

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

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? (0)

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

COBOL was never vibrant. never.

But it just fucking worked.

Very Disingenious (3, Interesting)

gauss72 (2927137) | about a year ago | (#43769997)

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.

And this is why people choose IBM (5, Insightful)

phantomfive (622387) | about a year ago | (#43769185)

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 (5, Insightful)

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

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 (1)

exabrial (818005) | about a year ago | (#43769241)

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 (0)

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

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 (1)

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

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

Re:And this is why people choose IBM (1)

CaptainJeff (731782) | about a year ago | (#43769393)

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 (0)

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

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 (2)

mendax (114116) | about a year ago | (#43769743)

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 (1)

gauss72 (2927137) | about a year ago | (#43770061)

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

Re:And this is why people choose IBM (0)

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

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 (1)

phantomfive (622387) | about a year ago | (#43769251)

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 (0)

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

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 (0)

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

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 (0)

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

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 (0)

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

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 (1)

bws111 (1216812) | about a year ago | (#43769901)

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 (0)

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

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...

Rebranding (4, Funny)

Chaos1 (466833) | about a year ago | (#43769207)

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

Re:Rebranding (1)

amiga3D (567632) | about a year ago | (#43769239)

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

Re:Rebranding (1)

funwithBSD (245349) | about a year ago | (#43769371)

You are lagging a little behind our market speak.

It would be CloudFlex or PureFrame.

Re:Rebranding (1)

game kid (805301) | about a year ago | (#43769463)

Don't you mean CloudFlxr, or pyUrFramely?

Re:Rebranding (0)

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

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.

Whippersnappers (0)

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

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 (1)

ebno-10db (1459097) | about a year ago | (#43769761)

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. [dilbert.com]

COBOL code is not too different (4, Interesting)

plopez (54068) | about a year ago | (#43769283)

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 (5, Funny)

93 Escort Wagon (326346) | about a year ago | (#43769491)

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 (0)

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

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 (1)

Howitzer86 (964585) | about a year ago | (#43769769)

This only works if you're a bending unit.

Re:COBOL code is not too different (1)

93 Escort Wagon (326346) | about a year ago | (#43769829)

Or a Series 4000 mechanoid.

So all the VBA programming in my masters program? (0)

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

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

Re:COBOL code is not too different (1)

Horshu (2754893) | about a year ago | (#43769547)

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.

Card reader (0)

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

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?!

Re:COBOL code is not too different (1)

mendax (114116) | about a year ago | (#43769691)

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].)

Kill it! (1)

Alejux (2800513) | about a year ago | (#43769295)

Kill it with fire!!!

Re:Kill it! (1)

iggymanz (596061) | about a year ago | (#43769397)

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! (0)

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

Says somebody completely ignorant of Java EE....

Cobol Analist (1)

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

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 (1)

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

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

Re:Cobol Analist (0)

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

In Soviet Russia, COBOL fucks YOU!

PROGRAMID. Harakiri. (0)

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

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

COBOL is just fine thank you (0)

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

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

Featured Listing (-1)

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

        Your Featured listing is displayed above all listings in your category, and also above all sponsored listings
        Traffic! We get thousands of Unique Visitors a day.
        We are indexed and crawled daily by Google, Yahoo, and MSN among others.
        Your site will be posted in 8 hours or less.
        Featured listing last for 1 year, then are converted to regular permanent links.

Obligatory (0)

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

http://www.coboloncogs.org/

Have any of the people griping USED COBOL? (4, Insightful)

khb (266593) | about a year ago | (#43769549)

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? (1)

mendax (114116) | about a year ago | (#43769681)

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? (1)

BlindRobin (768267) | about a year ago | (#43769839)

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? (0)

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

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.

Cue Lords of Cobol references in... (1)

davidwr (791652) | about a year ago | (#43769711)

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

COBOL: Cloud Oriented Business Objective Language? (4, Funny)

non-e-moose (994576) | about a year ago | (#43769985)

Change the acronym, now relevant to OO-fans.

what is cobol? (0)

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

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

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?