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 @02:43PM (#43769159)

    A stake and garlic? Anyone?

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

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

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

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

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


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

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

        • by gauss72 (2927137) on Sunday May 19, 2013 @05:42PM (#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 !
        • 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:Anyone? (Score:3, Insightful)

        by non-e-moose (994576) on Sunday May 19, 2013 @05:52PM (#43769983)
        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 @10: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.

    • by Virtucon (127420) on Sunday May 19, 2013 @06:43PM (#43770175)

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

      • by Lorens (597774) on Monday May 20, 2013 @06:44AM (#43772375) Journal

        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.

    • by Jeremy Erwin (2054) on Sunday May 19, 2013 @08:22PM (#43770601) Journal

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

    • by dkf (304284) <donal.k.fellows@manchester.ac.uk> on Monday May 20, 2013 @03:21AM (#43771977) Homepage

      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 @02:45PM (#43769165)

    Extended COBOL lifespan?!

    THANKS OBAMA! :(

    • Re:Ugh (Score:5, Funny)

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

      Never a death panel when you need one.

      • Re:Ugh (Score:5, Funny)

        by ColdWetDog (752185) on Sunday May 19, 2013 @03: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 @03: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 @04: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) on Sunday May 19, 2013 @04:17PM (#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?

          • by ColdWetDog (752185) on Sunday May 19, 2013 @05:10PM (#43769823) Homepage

            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 @02: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 @02:52PM (#43769211) Journal

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

    • by Samantha Wright (1324923) on Sunday May 19, 2013 @02:53PM (#43769217) Homepage Journal

      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.

      • by phantomfive (622387) on Sunday May 19, 2013 @03:09PM (#43769303) Journal

        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) on Sunday May 19, 2013 @03:41PM (#43769451) Homepage

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

      • by jd2112 (1535857) on Sunday May 19, 2013 @04:20PM (#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? (Score:5, Insightful)

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

    • Very Disingenious (Score:3, Interesting)

      by gauss72 (2927137) on Sunday May 19, 2013 @05:59PM (#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.
      • by serviscope_minor (664417) on Monday May 20, 2013 @07:01AM (#43772437) Journal

        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.

    • by flyingfsck (986395) on Monday May 20, 2013 @12:37AM (#43771557)
      COBOL is heading to the Cloud and will get 72 virgins...
    • by cyber-vandal (148830) on Monday May 20, 2013 @03:11AM (#43771947) Homepage

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

    by Chaos1 (466833) on Sunday May 19, 2013 @02: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 @03: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 khb (266593) on Sunday May 19, 2013 @04: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 @05:55PM (#43769985)
    Change the acronym, now relevant to OO-fans.
  • by Kittenman (971447) on Sunday May 19, 2013 @07:59PM (#43770497)
    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.
  • by manu0601 (2221348) on Sunday May 19, 2013 @08:34PM (#43770675)
    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.

If the code and the comments disagree, then both are probably wrong. -- Norm Schryer

Working...