Forgot your password?
typodupeerror
IBM Cloud Virtualization

IBM Takes System/z To the Cloud With COBOL Update 256

Posted by timothy
from the spirits-of-the-ancient-ones dept.
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."
This discussion has been archived. No new comments can be posted.

IBM Takes System/z To the Cloud With COBOL Update

Comments Filter:
  • Anyone? (Score:5, Funny)

    by Anonymous Coward on Sunday May 19, 2013 @03:43PM (#43769159)

    A stake and garlic? Anyone?

    • Re:Anyone? (Score:5, Funny)

      by Freddybear (1805256) on Sunday May 19, 2013 @03:52PM (#43769205)

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

      • by schnell (163007)

        Clearly COBOL will never die. As I recall, the civilization of Battelstar Galactica [wikipedia.org] had an entire religion devoted to the "Lords of COBOL [wikipedia.org]." 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? (Score:5, Funny)

      by Aighearach (97333) on Sunday May 19, 2013 @04:37PM (#43769429) Homepage


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

      • by goombah99 (560566) on Sunday May 19, 2013 @06:01PM (#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.

        • 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 fo
        • by ron_ivi (607351)

          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 [marc.info]

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

      • Re: (Score:3, Insightful)

        by non-e-moose (994576)
        Wait - you forgot the 3 pages of required COBOL prologue to create a "hello world" style program.
        • Re:Anyone? (Score:5, Interesting)

          by Aighearach (97333) on Sunday May 19, 2013 @11:29PM (#43771129) Homepage

          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.

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

      • by Lorens (597774)

        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.

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

    • by dkf (304284)

      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!

  • Ugh (Score:5, Funny)

    by Anonymous Coward on Sunday May 19, 2013 @03:45PM (#43769165)

    Extended COBOL lifespan?!

    THANKS OBAMA! :(

    • Re:Ugh (Score:5, Funny)

      by DarkOx (621550) on Sunday May 19, 2013 @03:49PM (#43769189) Journal

      Never a death panel when you need one.

      • Re:Ugh (Score:5, Funny)

        by ColdWetDog (752185) on Sunday May 19, 2013 @04:06PM (#43769277) Homepage

        The damned thing's immortal.

        IBM has found the secret to everlasting life!

        Surely, there is some money to be made here?

        • by PolygamousRanchKid (1290638) on Sunday May 19, 2013 @04:18PM (#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 (Score:5, Interesting)

          by ebno-10db (1459097) on Sunday May 19, 2013 @05:09PM (#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.

        • by jd2112 (1535857)

          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?

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

  • by lord_mike (567148) on Sunday May 19, 2013 @03:48PM (#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.

    • by decora (1710862) on Sunday May 19, 2013 @03:52PM (#43769211) Journal

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

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

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

      • by Aighearach (97333)

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

      • by jd2112 (1535857)

        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.

        • 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? (Score:5, Insightful)

      by Freddybear (1805256) on Sunday May 19, 2013 @03:56PM (#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.

    • by Viol8 (599362)

      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.

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

    • Very Disingenious (Score:3, Interesting)

      by gauss72 (2927137)
      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 am
      • 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 troggi

    • COBOL is heading to the Cloud and will get 72 virgins...
    • The cloud is just the 21st century rehashing mainframe concepts so why not use COBOL for it?

  • by phantomfive (622387) on Sunday May 19, 2013 @03:49PM (#43769185) Journal
    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.
    • by DarkOx (621550) on Sunday May 19, 2013 @03:53PM (#43769213) Journal

      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.

      • by exabrial (818005)
        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.
        • 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.

        • by mendax (114116)

          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.

          No

          • by 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 applic

      • 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.
    • by countach (534280)

      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.

      • 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.
  • Rebranding (Score:4, Funny)

    by Chaos1 (466833) on Sunday May 19, 2013 @03:52PM (#43769207) Homepage

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

  • by plopez (54068) on Sunday May 19, 2013 @04:06PM (#43769283) Journal

    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.

    • by 93 Escort Wagon (326346) on Sunday May 19, 2013 @04:48PM (#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.

    • 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 compil

  • by khb (266593) on Sunday May 19, 2013 @05:03PM (#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.

  • by non-e-moose (994576) on Sunday May 19, 2013 @06:55PM (#43769985)
    Change the acronym, now relevant to OO-fans.
  • 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.
  • 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.

The F-15 Eagle: If it's up, we'll shoot it down. If it's down, we'll blow it up. -- A McDonnel-Douglas ad from a few years ago

Working...