Forgot your password?
typodupeerror
Programming

COBOL Celebrates 50 Years 277

Posted by CmdrTaco
from the cobol-is-for-old-people dept.
oranghutan writes "The language used to power most of the world's ATMs, COBOL, is turning 50. It also runs about 75 per cent of the world's business applications, so COBOL should be celebrated for making it to half a century. In cricketing terms, that's a good knock. The author says: 'COBOL's fate was decided during a meeting of the Short Range Committee, the organization responsible for submitting the first version of the language in 1959. The meeting was convened after a meeting at the Pentagon first laid down the guidelines for the language. Half a century later, Micro Focus published research which showed people still use COBOL at least 10 times throughout the course of an average working day in Australia. Only 18 per cent of those surveyed, however, had ever actually heard of COBOL.'"
This discussion has been archived. No new comments can be posted.

COBOL Celebrates 50 Years

Comments Filter:
  • by bsDaemon (87307) on Monday September 21, 2009 @08:59AM (#29489973)
    Though, to be fair, 50 years isn't quite as long as the average cricket game.
    • by eclectro (227083)

      Though, to be fair, 50 years isn't quite as long as the average cricket game.

      Though, to be fair, with games lasting up to 5 days, [wikipedia.org] it just seems like 50 years.

    • Re: (Score:3, Funny)

      by Eudial (590661)

      Yeah, I almost had time to write a hello world program in COBOL during a cricket game once. Though I couldn't find enough Libraries of Congress to save it in, so I had to chuck it. A shame, really.

  • by Adeptus_Luminati (634274) on Monday September 21, 2009 @08:59AM (#29489987)

    "It also runs about 75 per cent of the world's business applications"

    Gee, I didn't know Windows Apps were coded in COBOL.

    Come on, 75% is a HIGHLY dubious claim. Where's the source / proof / evidence? Where I work, we have nearly 200 business apps and I'm pretty sure less than 2% of business apps were made in COBOL - possibly even 0%.

    Adeptus

    • by duffbeer703 (177751) on Monday September 21, 2009 @09:05AM (#29490053)

      Do you accept or make payment via credit card, check or ATM debit? Congratulations, you (indirectly) use COBOL.

    • by Archtech (159117) on Monday September 21, 2009 @09:05AM (#29490061)

      "It also runs about 75 per cent of the world's business applications"

      Gee, I didn't know Windows Apps were coded in COBOL.

      They can be, using the excellent Microfocus COBOL or many other implementations.

      But actually, only a very few of the world's (important) business applications run on Windows. Seriously. Big heavy-duty transaction-processing apps run overwhelmingly on mainframes, because they just work.

      • by drinkypoo (153816) <martin.espinoza@gmail.com> on Monday September 21, 2009 @09:35AM (#29490361) Homepage Journal

        I think what we're arguing over here is the application of the English language. As the sentence is written, it is probably incorrect. Due to logarithmic growth, it is virtually impossible that the numbers come out right. If one said that 70% of business transactions were facilitated through COBOL at least in part then it might be true, because of all the legacy code still doing its job out there at banks and other financial institutions.

        Mainframes are breathing their last gasp; they will soon exist only in cases where you need very fast access to all of very large data sets. And honestly, clustering filesystems and databases are solving that problem too. Clusters will rule nearly every aspect of large computing because they are the only thing more reliable than a mainframe.

        • by SanityInAnarchy (655584) <ninja@slaphack.com> on Monday September 21, 2009 @10:10AM (#29490863) Journal

          they will soon exist only in cases where you need very fast access to all of very large data sets.

          Which is quite often.

          And honestly, clustering filesystems and databases are solving that problem too.

          Except that clustering filesystems almost always have to compromise on one of the ACID properties. For example, Amazon's Dynamo and CouchDB are highly available, redundant, and fast, but allow conflicts, assuming the application will correct for them. Ok, but that fails for a banking application -- if I were to withdraw my entire balance from two different nodes simultaneously, I'd have a massive overdraft, but I'd also have the money.

          You could imagine trying to shard it instead, but what happens when you transfer money between two shards? You still need a transaction, only now it needs to be synchronized between two nodes. What do you do? Do you lock both nodes at once? Now you've got a possibility of deadlocks.

          Clusters will rule nearly every aspect of large computing because they are the only thing more reliable than a mainframe.

          Reliability can be defined in several ways. Clusters are more available than a mainframe -- if your mainframe goes down, you're down. But clusters are less consistent than a mainframe, unless you're willing to take such massive hits from synchronization that the performance advantage is gone.

          For the vast majority of applications, some inconsistency is acceptable. Take Amazon's example -- if you tell one node to add item A to your cart, and another node to add item B, producing two conflicting versions of your cart, the cart application should be smart enough to merge them. The only synchronization needed is checkout, and here, all you'd need to do is refer to a specific version of that record in the form that's submitted.

          But for applications which can't tolerate that inconsistency, unless there's some clustering method I'm unaware of, you're still going to want something like a mainframe.

          • by VAXcat (674775)
            VMS clusters, with the Distribute Lock Manager, solved this problem decades ago.
        • by TheSunborn (68004)

          Mainframes are breathing their last gasp; they will soon exist only in cases where you need very fast access to all of very large data sets.

          Why would you need a mainframe just for that? A fully upgraded SGI Altix 4700 will be faster then IBM's fastest mainframe and I also think that HP's superdrome is up there in performance.

        • Re: (Score:3, Interesting)

          by baegucb (18706)

          Where I work we benchmarked database performance on existing servers vs. a Linux partition on the mainframe. Performance was 5 times faster on the mainframe. Massively parallel high speed IO made the mainframe faster So now we are converting stuff over to the mainframe. And if we want near 100% uptime, it's done on the mainframe, so the most important web sites run on the mainframe.

          I do agree with your comment though about the 70% of transactions.

          As a side note, COBOL is an easy language, but others are mor

      • by MBGMorden (803437) on Monday September 21, 2009 @09:37AM (#29490391)

        I have to agree. We recently switched parts of our tax billing software from an old COBOL system running on an AS400 to Windows. There were some legitimate concerns involved - creating a graphical sketch wasn't possible on a text-mode system, and tax laws change very frequently, and the old system was just becoming difficult to maintain.

        So, we switched to a Windows app with a SQL Server backend. FWIW the database backend has been rock-solid, but the actual client? It's junk. That old clunky COBOL system might have been awkward to use and a bit long in the tooth, but it NEVER crashed, and its mistakes were minimal to say the least. This new Windows system crashes constantly (including crashing if you work too fast - yeah I literally have to do a "one one-thousand" count when switching between properties or the client will lock up), and it goofs up the data frequently enough that in another 5 years I think our data will be reduced to an unreliable mess.

        Truthfully though, it's not the fault of Windows, or whatever language the newer apps are written in (Visual Basic in the case of our new pile o' junk). You can certainly write good stuff in new languages on new systems. I think it's a two-fold problem. One, the complexities of a GUI makes codes many times more intricate, making the job more difficult (and more error prone), but also, programmers today look at problems differently. They program for "features" first so they can give a good sales presentation. In the old days it seems like a reduced feature set was fine so long as your code was done right. That's not the case anymore, which is a shames, because on most of our newer systems we use MAYBE 20% of of the features included, and I'd gladly trade the other 80% for stability and accuracy.

        • by sgbett (739519) <slashdot@remailer.org> on Monday September 21, 2009 @09:44AM (#29490499) Homepage

          I don't think its the languages that are getting worse...

        • Re: (Score:3, Insightful)

          One, the complexities of a GUI makes codes many times more intricate, making the job more difficult (and more error prone),

          I doubt this is much of an issue. GUIs can certainly be abstracted to the point where it's not an issue.

          programmers today look at problems differently.

          Well, some programmers. (Hire me!)

          I do agree, but recent programmers certainly don't have a monopoly on WTFs. I think you've got something of the success effect here -- that is, your old COBOL system was necessarily reliable, because if it wasn't, it wouldn't have lasted this long. So the old COBOL apps that are still in production are likely at least somewhat reliable.

          But reliable and maintainable are di

        • by wisty (1335733)

          Agile programming focus on a reduced feature set that is actually tested.

          I would guess there were lots of programs written 30 years ago that were crap, but you can bet that they didn't last. COBOL programs are only survivors because they got them right the first time.

        • creating a graphical sketch wasn't possible on a text-mode system

          Unless the text-mode system can output an SVG document for a graphical client to display.

          on most of our newer systems we use MAYBE 20% of of the features included, and I'd gladly trade the other 80% for stability and accuracy.

          All clients use the same basic 10% of the features, but they have a different other 10% that they use. Once software became off-the-shelf rather than bespoke, software publishers started to try to include every client's other 10% in the same product.

          • by MBGMorden (803437)

            Unless the text-mode system can output an SVG document for a graphical client to display.

            Well, yes, and that was sort of the case with the old system. Building dimensions were entered in a specific text format that we could easily take and convert to graphical (which we did during the data conversion), but what the users mostly wanted was a graphical input method. Rather than typing out the dimensions they just wanted to draw them, which was just not possible with a "green screen" application.

        • I think it's a two-fold problem. One, the complexities of a GUI makes codes many times more intricate, making the job more difficult (and more error prone), but also, programmers today look at problems differently.

          They sure do! Naive new programmers used to write programs that handled large amounts of data as batch jobs. Naive new programmers write programs that handled large amounts of data as event-driven GUI constructs. Hint: MVC. Second hint: MVC. Need another: MVC.

          Even GUI code can be pretty simple when you enforce a strict separation between the interface and the backend. Write your underlying code first and get it perfected (or as perfect as your time and money budgets allow), and only then write a GUI t

        • by orzetto (545509) on Monday September 21, 2009 @11:58AM (#29492317)

          Visual Basic

          I think I see your problem here...

          One, the complexities of a GUI makes codes many times more intricate [...]

          Here's the rest of your problem. A GUI must never bump into a difficult or mission-critical algorithm. That's supposed to be its own library, which is accessed by the GUI through a clean and solid software interface. This is a major architectural fault: a Big Ball of Mud [laputan.org], and some languages encourage that more than others.

          My suggestion would be: get a language with a lower density of script kiddies, sufficiently popular and object-oriented (Python, C++, Java, ...), get some good programmers with proven track record, and rewrite the client. Specify that you want all functions and variables documented, and test suites; if they say "that will cost you more", show them the door. If they say "we do it anyway", that's a good sign.

    • by Fred_A (10934) <(fred) (at) (fredshome.org)> on Monday September 21, 2009 @09:15AM (#29490167) Homepage

      Come on, 75% is a HIGHLY dubious claim. Where's the source / proof / evidence?

      Actually if just Solitaire was coded in COBOL it would seriously skew the statistics already, numerous people would spend hours poking at a COBOL app each day.

    • by Old97 (1341297) on Monday September 21, 2009 @09:15AM (#29490171)

      The wording is misleading. Perhaps it's more accurate to say that 75% of business computing by value depends on COBOL. I've worked at a number of places in the financial services industry and have a lot of friends who do as well. All of our core business functions are still in COBOL. A lot of the data is still in VSAM, IMS and Model 204 legacy stores. A lot of what is in DB2, an RDBMS, is VSAM files converted directly to tables instead of truly relational databases.

      The fun stuff (Java, .NET, Web) runs the outward facing services and peripheral functions, but claims processing, credit card reconciliation, billing, accounting, etc. is still in COBOL. The computer industry press spends a lot of time admiring the new chrome and fins and that new built-in radio with FM, but business is still powered by the COBOL drive train running on mainframes.

      Even the clued in managers want to get off of it and onto more flexible systems and more productive languages, but it's too scary (risky) because they are afraid to break something. No one knows what the business rules are because they are embedded hither and yon in COBOL programs.

      • And why would you change it? After all: Never change a working system.

        You would not go an change anything foundational, if there isn't a reason to do so. What would the reason be in this case?
        Maintainability does not really become harder for the same piece of code. Except if you constantly change things. Only the maintainers become more rare. But there is no reason they have to.

        Hmm... what about the following solution: Stop changing *anything* in the basic COBOL code. If you change something, do the transfo

      • by smcdow (114828)

        The fun stuff (Java, .NET, Web) ...

        If by "fun", you mean "hammering #10 nails into my eyeballs", then I agree.

    • Lack of knowledge (Score:4, Interesting)

      by zoomshorts (137587) on Monday September 21, 2009 @09:32AM (#29490327)

      Most businesses did not see any need to port mainframe stuff to WinDoze.
      COBOL is solid. WinDoze is flakey. RM COBOL extended COBOL to modern
      programmers. If it isn't broke, you don't 'fix' it.

      Get a grip, and learn. I suggest going back to school. Just my opinion
      though.

      "Come on, 75% is a HIGHLY dubious claim. Where's the source / proof / evidence? Where I work, we have nearly 200 business apps and I'm pretty sure less than 2% of business apps were made in COBOL - possibly even 0%."

      I suggest YOU go to work for any major business and work on their accounting software. Highly dubious? Hardly. Your business 'Apps' are probably front ends for a real language on a mainframe.
      Visual this or that.

      • COBOL is solid. WinDoze is flakey.

        False dichotomy. Even IBM is selling Linux on mainframes these days.

        If it isn't broke, you don't 'fix' it.

        If it's not maintainable, it's broke.

        Visual this or that.

        If you pull your nose out of your COBOL for a few minutes and bother to actually learn something, you'll find that Microsoft is one small part of a large ecosystem of languages and development tools, most of which are not called "visual" anything, and most of which are better than COBOL.

      • COBOL is solid. WinDoze is flakey.

        I agree, but so what? COBOL is a programming language; Windows is an operating system. I could replace your statement with "C++ is solid. VAX/VMS is flakey." and it would make as much sense to your argument.

        I suggest YOU go to work for any major business and work on their accounting software.

        How major? GM, Walmart, Citibank? Sure they have mainframes running COBOL apps, but most businesses are not that "major", and the "minor" ones outnumber them significantly. Also,

    • Re: (Score:3, Insightful)

      by MikeBabcock (65886)

      What are you, a college student? You honestly believe anywhere near 75% of the world's business applications runs on Windows?

      Microsoft only wishes it had the big iron servers that do the fun stuff like banking and credit card processing.

  • by davidwr (791652) on Monday September 21, 2009 @09:01AM (#29490005) Homepage Journal

    People "use" applications and embedded systems.

    It would be more accurate to say people use applications written in the language several times a day.

    I wonder how many times people use applications written in C or languages common to embedded systems? What languages, for example, are used to create the code that makes their automobiles, home entertainment centers, voicemail, etc. work?

    How many times a day do people use applications that rely other languages that predate the moon landing?

    • How many times a day do people use applications that rely other languages that predate the moon landing?

      It would be interesting to see a graph of the ages of the languages people use/encounter (even, as with COBOL, unwittingly). I expect it would be an inverse bell curve, perhaps even a bathtub curve with steep walls at each end...

      It would serve as a powerful lesson for language developers and programmers to quit mucking around with the latest 'paradigms' and programming fads and to concentrate on

  • COBOL (Score:5, Funny)

    by mcgrew (92797) * on Monday September 21, 2009 @09:02AM (#29490019) Homepage Journal

    Happy birthday, Crappy Old Bad Obsolete Language! You need to take better care of yourself, you look a lot older than fifty.

  • by Anonymous Coward on Monday September 21, 2009 @09:07AM (#29490071)

    ... and GET OFF MY LAWN!

  • by walkoff (1562019) on Monday September 21, 2009 @09:11AM (#29490123)
    We were taught COBOL at college 25 years ago and i'm still a grumpy old git
    • by DarthVain (724186)

      9 Years ago for me.... Wonder if they are still teaching it.

  • Typo (Score:4, Funny)

    by winnitude (1352731) on Monday September 21, 2009 @09:14AM (#29490159)

    "COBOL Celebrates 50 Years"

    Should read:

    "COBOL Bemoans 50 Years"

    • Nah! COBOL is celebrating. It's the COBOL programmers that are bemoaning. Or at least moaning.

  • Not So Bad (Score:5, Insightful)

    by Ancient_Hacker (751168) on Monday September 21, 2009 @09:29AM (#29490301)

    COBOL did a lot of things right, things that a lot of modern languages ignored.

    Little things like:

    * Having a manufacturer and machine and OS-independent standard.
    * Quasi human-readable code.
    * "MOVE CORRESPONDING"

    that said, it's just as easy for numbskulls to write bad COBOL as to write bad C++ or bad Ruby.

    • by Chrisq (894406)
      I'm not so sure about the "MOVE CORRESPONDING", I think that this can be better addressed wit inheritance. The one thing that COBOL does better than any mainstream modern language is record handling and formatting. I know that expert programmers can do the same thing with "C" printf statements and Java SimpleXXXFormat classes but in COBOL it was fairly easy and could be handled by trainee programmers with a low error rate.
      • The one thing that COBOL does better than any mainstream modern language is record handling and formatting.

        Formatting? Really?

        Record handling, I dispute. Formatting, if it was really so much better, I'm sure I can build a library to replicate it.

      • My knowledge of COBOL is limited to what I remember from a summer class between my junior and senior years of high school, many years ago. I have worked extensively in the Foxbase and Foxpro variants of 'xbase', and they always felt to me like a mix of Pascal, BASIC, COBOL and Fortran - the COBOL mostly in the PICTURE clauses available to some commands.

    • by Virak (897071)

      that said, it's just as easy for numbskulls to write bad COBOL as to write bad C++ or bad Ruby.

      People like to say the same sort of thing about PHP and VB. What they neglect to consider is that all of these languages try to be seen as and are seen as numbskull-friendly languages, and thus have a wholly disproportionate amount of numbskulls using them. Furthermore, while it may be just as easy to write bad code in any language, how easy it is to write good code is very dependent on language and just as import

      • Also, many people would probably consider the second item of your list one of the greatest failings of COBOL; specialized notations are usually used for specialized purposes for good reason.

        Yet we don't want all languages to become APL-style inscrutable symbol-fests either. For example, Python uses "and" where PHP and C use &&, and Python uses "is not" where (roughly) PHP uses !==. If a manager can quickly learn to read the notation without it impeding other desirable features, that's a plus (or should I say a +).

        Compare "add 1 to cobol" to "c++".

        • by Virak (897071)

          Python is easily the language I use the most, so I'm quite familiar with it. The big difference is that Python merely uses English keywords in place of a few symbols. This isn't a particularly radical difference, most languages already make extensive usage of keywords, and using "and" instead of "&&" doesn't significantly bloat your source code (and e.g., "||" and "or" have the same length). COBOL, however, tries to be like English and not just something that uses English words here and there.

          If a m

    • Re: (Score:3, Insightful)

      by ChienAndalu (1293930)

      * Quasi human-readable code.

      Human readability doesn't count. You have to understand it too. Cobol uses English words instead of a more concise syntax with special characters, and is therefore more difficult to understand. Mathematical equations and chemical formulas have their special syntaxes, and computer programs should have them too.

      that said, it's just as easy for numbskulls to write bad COBOL as to write bad C++ or bad Ruby.

      Obvious. But can you show me *good* COBOL?

    • Re: (Score:3, Interesting)

      by Hurricane78 (562437)

      I disagree with the assumption that it's "just as easy". In some languages, it's definitely easier to write bad code. PHP is such an example. C/C++ is another one. In PHP it comes with the retardedness of the language. In C/C++ it comes with the freedom.

      A good example for a language that has certain things in place to prevent bad coding, is Haskell. Type problems in running code are (except for the external input reader) simply impossible.

      • Re: (Score:3, Insightful)

        by orzetto (545509)

        A good example for a language that has certain things in place to prevent bad coding, is Haskell.

        I have been studying some Haskell in the past few months, and while I am in awe at Haskell's type system, and how you can write a language without for and while, and lazy evaluation, and functional purity, and partial application, and so on, there are two things that made me give up:

        1. Functional purity makes I/O a major mess. Monads are complex, unintuitive and unwieldy. I think I spent over one month only trying
  • ... "apt-get install open-cobol" would actually work. Yegads...
  • Happy 50th (Score:5, Funny)

    by CharlyFoxtrot (1607527) on Monday September 21, 2009 @09:40AM (#29490443)

    identification division.
    program-id. birthday.
    environment division.
    data division.
    procedure division.
    main section.
    display "get off my lawn!"
    stop run.

    • 10 REM Comeback
      20 PRINT "Who's gonna make me, you and ALGOL?"
      30 END
    • Re:Happy 50th (Score:5, Informative)

      by Anonymous Coward on Monday September 21, 2009 @10:38AM (#29491263)

      000100 IDENTIFICATION DIVISION.
      000200 PROGRAM-ID. CONGRATS.
      000300
      000400*
      000500 ENVIRONMENT DIVISION.
      000600 CONFIGURATION SECTION.
      000700 SOURCE-COMPUTER. RM-COBOL.
      000800 OBJECT-COMPUTER. RM-COBOL.
      000900
      001000 DATA DIVISION.
      001100 FILE SECTION.
      001200
      100000 PROCEDURE DIVISION.
      100100
      100200 MAIN-LOGIC SECTION.
      100300 BEGIN.
      100400 DISPLAY " " LINE 1 POSITION 1 ERASE EOS.
      100500 DISPLAY "Congratulations with your 50th birthday" LINE 15 POSITION 10.
      100600 STOP RUN.
      100700 MAIN-LOGIC-EXIT.
      100800 EXIT.

  • Longevity (Score:5, Insightful)

    by wandazulu (265281) on Monday September 21, 2009 @09:48AM (#29490563)

    I worked at a company that had a Cobol-based program that went live back in 1969. A team of programmers had kept it going ever since. Shortly after I started (mid 1995), I was in a meeting when one of the Cobol programmers mentioned that so-and-so had died over the weekend. Everybody started talking about her, what a great person she was, etc. After the meeting, I asked who she was, and was told that she was the last surviving member of the original team that wrote and deployed the application. When the system was finally shut down back in 2003 or so (I had long since left, but still had some contacts there to tell me what was going on), I really felt weird about hearing it; here was this thing that had outlived its creators (and some of the later maintainers), and now it was gone too.

    Isn't it strange how computer software is both unbelievably ephemeral, yet also incredibly long-lived. I've worked on both sides and I'm not sure which is more fulfilling; it apparently took several years to write the aforementioned Cobol program, but it outlived its creators. I wonder what a programmer on something like, say, Madden, would feel, knowing that this thing they're working so hard on will be totally supplanted by the next version, next year.

    Strange business, this computing machinery. Strange indeed.

    • Re: (Score:3, Interesting)

      by Ollabelle (980205)
      I can believe it would have taken a long time to write one of those programs. When I was in college back in the late 70's, my first programming class was in Fortran, and one assignment was a simple look-up table to determine how much to charge for a taxi service between different locations using different vehicles. At this time, it was all punch cards, so excluding the start and stop cards, the whole program was about 12 - 15 cards. AFterward, the professor announced that this same program in the COBOL c
    • by bbtom (581232)

      Well, ideally, they'd be able to get excited about doing it differently, maybe doing it better. We have to reconcile ourselves to the fact that non-programmers may make decisions about software for less-than-optimal reasons (A: "We're using XML"; B: "Why?"; A: "Well, anything that begins with 'X' has to be cool and the industry press has talked it to death."; B: "But, but..."; A: "I pay your salary."; B: "Okay then. I'll just take our CSV data and wrap it in a 'CSVData' element."), but that we can at least

      • Re: (Score:3, Insightful)

        Well, ideally, they'd be able to get excited about doing it differently, maybe doing it better.

        Le mieux est l'ennemi du bien. (The better is the enemy of the good.) - Voltaire

        Might be anecdotal but I've seen a few perfectly good system thrown out in the search for an ephemeral "better" that then failed to materialize.

    • Isn't it strange how computer software is both unbelievably ephemeral, yet also incredibly long-lived. ... I wonder what a programmer on something like, say, Madden, would feel, knowing that this thing they're working so hard on will be totally supplanted by the next version, next year.

      I'm not sure where your career path has taken YOU over the years, but many (most?) of us reading this ARE that programmer you're curious about. Just about every major project I've ever worked on either failed due to a manage

  • The use of COBOL cripples the mind; its teaching should, therefore, be regarded as a criminal offence.
    Edsger W.Dijkstra, 18 June 1975
  • Funnily enough, 50 years is half a century in ... you know, the ENGLISH LANGUAGE (and I'm sure it's also half of the foreign equivalents to the word century. Except in Russia, of course).

  • by TimSSG (1068536) on Monday September 21, 2009 @10:12AM (#29490893)
    How is SNOBOL doing? Better or worse than COBOL? Tim S.
    • by idiot900 (166952) *

      SNOBOL dropped out of high school and ended up working for a car dealership, last I heard. He was always the sleazy sort.

  • As they enjoy spending money for obvious, I suggest them to ask those general and professional Apple users (Macbook and iPhone included) if they know UNIX and if they know it celebrates its 40th year today. In fact, start with NeXT.

  • and still very much alive.

    You cannot kill it (quite literally, mainframes have a MTBF of what, 40 years? How is your windows box doing?).

    You can sneer at it, disregard it, ridicule it. But it is still there after decades of getting bad rep and no fresh blood. That is actually pretty impressive.

  • ...and I'm happy for you and all, but FORTRAN was the best old-school language of all time!
  • a few slogans we could tag this one with:
    COBOL: yeah but the frontend is java.
    COBOL: and so the AS400 is in the inventory once again.
    COBOL: break it and we're fscked.
    COBOL: ...so i CAN use goto?
  • EOM [/could not resist, and yes there are some young ones out there].

    http://www.reuters.com/article/pressRelease/idUS121649+18-Sep-2009+PRN20090918 [reuters.com]

  • For any of you tempted to wax nostalgic about COBOL, let me explain[*] just one charming feature: Procedure calls in COBOL are not stack based. That's right, there is no call stack.

    In fact, you can't even really call a procedure in COBOL. Instead, you invoke what amounts to a GOTO/COMEFROM [wikipedia.org] pair. COBOL programs are divided into "paragraphs". When you want to execute a procedure, you PERFORM PARA-1 THRU PARA-N. Yes, that's right - the return point of the invocation varies at the whim of the caller. Heck, the

  • COBOL Joke (Score:5, Funny)

    by Haxzaw (1502841) on Monday September 21, 2009 @11:21AM (#29491833)
    Jack was a COBOL programmer in the mid to late 1990s. After years of being taken for granted and treated as a technological dinosaur by all the Client/Server programmers and website developers, he was finally getting some respect. He'd become a private consultant specializing in Year 2000 conversions. Several years of this relentless, mind-numbing work had taken its toll on Jack. He began having anxiety dreams about the Year 2000. All he could think about was how he could avoid the year 2000 and all that came with it. He tried getting a job with an Orange County web development firm, but couldn't hack it in the end. Jack decided to contact a company that specialized in cryogenics. He made a deal to have himself frozen until March 15th, 2000. The next thing he would know is he'd wake up in the year 2000; after the New Year celebrations and computer debacles; after the leap day. Nothing else to worry about except getting on with his life. He was put into his cryogenic receptacle, the technicians set the revive date, he was given injections to slow his heartbeat to a bare minimum, and that was that. The next thing that Jack saw was an enormous and very modern room filled with excited people. They were all shouting "I can't believe it!" and "It's a miracle" and "He's alive!". There were cameras (unlike any he'd ever seen) and equipment that looked like it came out of a science fiction movie. Someone who was obviously a spokesperson for the group stepped forward. Jack couldn't contain his enthusiasm. "Is it over?" he asked. "Is the year 2000 already here? Are all the millennial parties and promotions and crises all over and done with?" The spokesman explained that there had been a problem with the programming of the timer on Jack's cryogenic receptacle, it hadn't been year 2000 compliant. It was actually eight thousand years later, not the year 2000. Technology had advanced to such a degree that everyone had virtual reality interfaces which allowed them to contact anyone else on the planet. "That sounds terrific," said Jack. "But I'm curious. Why is everybody so interested in me?" "Well," said the spokesman. "The year 10000 is just around the corner, and it says in your files that you know COBOL".
  • I invented a similar language once called BOLOC. But I never had the balls to carry it through to market.
  • tags (Score:3, Insightful)

    by smoker2 (750216) on Monday September 21, 2009 @12:15PM (#29492545) Homepage Journal
    Which prick tagged this !kobol ? Does it SAY kobol anywhere in the title, summary or article ? Or is so that you can easily search for kobol later and not find this story (in which case you could have saved your typing) ? FFS. Next time there is a story about google I'm going to tag it !poodle.
  • This is not a joke.

    * "Hello world" program
          *
          DISPLAY `Content-type: text/html`.
          DISPLAY LINEFEED.
          DISPLAY `<HTML><BODY>`.
          DISPLAY `<CENTER>Hello World</CENTER>`.
          DISPLAY `</BODY></HTML>`.

    Yes, server side scripting in interpreted COBOL.

  • It works (Score:2, Informative)

    by cjonslashdot (904508)
    Mainframe transaction platforms are rock solid - much more than one can say for most web app platforms.

Time sharing: The use of many people by the computer.

Working...