Forgot your password?
typodupeerror
IBM Hardware IT

The Mainframe World Is Alive, Even For Those Under 40 361

Posted by timothy
from the onions-on-belts-and-snowshoe-flippers dept.
willdavid writes with a link to a report by Jeff Gould at Interop Systems, about the definitely-still-around world of mainframe computing, from which he extracts: "Last week I had the occasion to visit SHARE, the premier mainframe conference, which was held in San Jose just down the road from where I live. Based on what I saw, there is one thing I can tell you for sure, and that is that Cobol is not dead. And neither is the mainframe. When I mentioned to one of my friends that I had been to SHARE, he joked that it must have looked like an AARP convention. But this turned out not to be so. While there were certainly a few 60-somethings strolling around the halls, the under 40 generation was also well represented. What struck me the most was not the advanced age of the people but the relative youth of a lot of the software being discussed." However, it's not all fountain of youth there, either. (Thanks, BDPrime.)
This discussion has been archived. No new comments can be posted.

The Mainframe World Is Alive, Even For Those Under 40

Comments Filter:
  • Not surprising.... (Score:5, Insightful)

    by Anonymous Coward on Thursday August 21, 2008 @07:20PM (#24697549)

    The ol' yellow number 2 pencil is still around as well, as is shoe-making, wine-barrel repair, and of course the oldest tool in the book ... the tool.

    Like humans all technologies find their place in the universe. Mainframes have their advantages, just would not want one sitting on my lap.

  • by Tubal-Cain (1289912) on Thursday August 21, 2008 @07:29PM (#24697655) Journal

    For many people, the image of a mainframe computer is a complex of dozens of refrigerator-sized cabinets containing tape drives, disks, processors, and communications hardware located in a freezing room, consuming enough electricity to power a small city.

    And is that image mistaken?

  • Re:Need... (Score:5, Insightful)

    by geekoid (135745) <dadinportlandNO@SPAMyahoo.com> on Thursday August 21, 2008 @07:47PM (#24697875) Homepage Journal

    99.999 Up time, speed, number of transactions, precision, hot swapping, 64 CPUs, lower cost to maintain, longer life time.

    Hell, I can get a mainframe and put 30,000 Linux instance on it and use it as a cluster, or rollover servers.

    PC Servers still aren't as capable as a mainframe, not even clusters.

  • by PingXao (153057) on Thursday August 21, 2008 @07:48PM (#24697889)

    I was at the last winter conference in Orlando. I would guess the median age of the attendees was somewhere around 40. There's a LOT of Linux going on in the mainframe world (and COBOL has nothing to do with it). The biggest mistake IBM is currently making IMO is they've gotten into bed with Suse. There was a large group from Suse (Germany) in Orlando last February. Again IMO, Suse is an awful Linux distro. Yast is an abomination to work with on a daily basis. I think Redhat missed the boat there even though their Enterprise Linux distribution has support for System 390 hardware. Anyway, the point is that Linux is alive and well and thriving on big iron.

    In addition, one of the primary draws of Orlando is Disney World and the other nearby theme parks. The (oops, almost wrote "Teh" there) February conference was held IN Disney at the Coronado Springs (stay in the Cabanas section if you ever go there, for any reason). SHARE members vote on where to hold their meetings. If a majority of those folks were over 60 I doubt they'd continue returning to Orlando every few years.

    If you're not familiar with where and how mainframes are being used today then I suggest that YOU are the one who's out of touch with a significant sector of the computing world. Business' needs don't all revolve around iphones, ajax and youtube. Or payroll and accounting, for that matter.

  • by Rossjman1 (1272538) on Thursday August 21, 2008 @07:52PM (#24697927)

    I'm taking a Cobol class as we speak (literally... I'm in class)

  • by jackspenn (682188) on Thursday August 21, 2008 @07:56PM (#24697953)
    The only reason that we still run a mainframe is because the management in place grow up around the mainframe and their underlings would be put out of work if we got rid of it. There is no reason why we couldn't be moving all of its relatively simple programs from the mainframe to a JAVA or .NET other then the fact that we have to wait for all of the current decision makers to retire or just die. The money we waste on hardware components or in turning on software features that are free in most other parts of the industry as well as the time it takes for old farts to get their head around distributed computing concepts is insane. While they spend days writing a program to do screen scraping to get an answer for management "How many people work here?" before eventually conceding they are unable to get the correct result only to have management come to me for a 2 minute powershell script to get the same information from AD. Yes we store things one way in the mainframe and again in AD or SQL Databases because the mainframe people are scared to try and cross the bridge and work with us. They freak out at anything new and worse they don't how the mainframe works. I read all about the Z/9 in an attempt to relate to those bums, I walked over to their side of the hall and in 15 minutes realized the operators don't care to learn how or why something is, they prefer to think of it as a black box. A big black box that takes up lots of room, lots of power and lots of cash. IBM mainframes exist because people who fear change are unable to get off them, not because there is anything fundamentally advantageous about them. I am planning their destruction, a VM that runs on Intel hardware but responds just like a mainframe, it is software that could be sold for nothing and then all the mainframe apps could be moved to it and IBM would be finished, dead toast. I think it is sad you have to pay and enter a code if you want to see more HD space, you cannot just plug in more SAN space, you have to buy it like you would for the Intel side and then pay IBM to let you see it. It is just a revolting way of doing IT. Mainframes are not innovative people, Mainframes are not sex or cool. Mainframes are anti-hacker, anti-explorer, anti-learning. I cannot stress how much they suck.
  • by Enleth (947766) <enleth@enleth.com> on Thursday August 21, 2008 @07:58PM (#24697971) Homepage

    As far as the general principle of operation is concerned, your average nuclear (or coal/natural gas/oil, for that matter) power plant is a huge steam engine attached to a generator. Sure, it uses a turbine instead of a piston, but there AFAIK were some attempts at a turbine-based steam engine of a more typical size and use, they just came too late for the techology to be used for transportation. So it got to be used for generating electricity on a massive scale.

  • Re:Need... (Score:3, Insightful)

    by betterunixthanunix (980855) on Thursday August 21, 2008 @08:05PM (#24698025)
    A lower end mainframe can replace roughly 1000 commodity servers, or so I've been told. It consumes roughly 10kW of power and requires only one operator to keep it functional (well, assuming 8 hours shifts, 3 operators). Those 1000 commodity servers will be consuming ~100W a piece, so the overall power consumption will be 10 times higher than the mainframe, and will probably require at least 3 administrators on the clock at any given time (so going with non-overlapping 8 hour shifts, that's 9 administrators). The cost savings could easily justify the expense of the mainframe, assuming that you are an institution that uses 1000 or more commodity servers.
  • by Shinobi (19308) on Thursday August 21, 2008 @08:10PM (#24698079)

    The Google model is not applicable for the tasks where mainframes are used. Mainframes are used for high-throughput/high availability/high RELIABILITY as well as high-INTEGRITY operations. In contrast, with Google, if a server dies, leaving 50 queries in Limbo, well, the internet users will just have to try their luck again, and hope for the best.

  • Re:Need... (Score:5, Insightful)

    by awyeah (70462) * on Thursday August 21, 2008 @08:10PM (#24698081)

    That's correct. Also, look at the retail business. Merchandise management, loss prevention, warehousing and distribution... And we're not talking arcane software packages.

    Here's an example: A retail chain has payroll, merchandising, and warehousing/distribution systems, all on the mainframe. The point of sale interfaces with the mainframe as well. A store starts to run low on an item? The mainframe knows because the POS sends its inventory data constantly. The MMS then tells the warehousing system that that store needs more. A pick list is automatically printed by the warehousing system. The warehouse worker picks the item off the shelf, puts it on a conveyor belt which runs through an RFID portal, linked to the mainframe, that then routes the item to the proper truck in the dock so it gets to the correct store - automatically. The truck delivers the item to the store, and the driver enters that into a wireless device which (you guessed it!) tells the warehousing system and merchandise management system that the item has been received by the store, so the MMS always knows the inventory levels in the store. The associate sells that item, and the MMS sees that from the POS data... it also knows that this particular item pays out a spiff to the associate and sends the information directly to the payroll system, which interfaces with a company who handles payroll (like ADP), and automatically adds the spiff to their next paycheck.

    Uh oh - the chain is growing and adding new stores, with increasing volumes of data to process, and the nightly batch processing is taking too long... what to do? Call IBM, license another processor... They activate it immediately for you.

    But oh no! A disk is failing... no need to worry, because IBM already knows about it and has dispatched a technician to diagnose and replace the faulty hardware.

    New versions of this software are being released all the time, and just about every retailer with more than a few stores uses them. These systems are modern. Don't think a big room full of giant cabinets, reel-to-reel tapes and punch cards. Some of the current IBM iSeries (AS/400) models have a form factor that looks more like a PC than a mainframe.

    Show me a Windows or Linux system that can do all that, 24x7, for hundreds or thousands of stores.

  • by jstott (212041) on Thursday August 21, 2008 @08:19PM (#24698147)

    I am planning their destruction, a VM that runs on Intel hardware but responds just like a mainframe, it is software that could be sold for nothing and then all the mainframe apps could be moved to it and IBM would be finished, dead toast.

    And it'll run under Vista to guarantee 24-7 reliability!

    There's a lot more to a mainframe than just software apps — reliability and massive I/O being the most obvious. Remember, this is a world where down-time is measured in millions of dollars per hour. Mainframes are specialized tools designed for specialized jobs and no PC will ever displace (regardless of what sexy VM you're trying to hype) them simply because PC's are designed for a broad consumer market and not for the 24-7 zero-downtime business world.

    -JS

  • by sphealey (2855) on Thursday August 21, 2008 @08:38PM (#24698383)

    === But COBOL? Sure, there's legacy COBOL code that needs to be maintained. But answer this question: Given a clean slate and a proposal to build a new application, how many people would choose COBOL? Anybody? ===

    Serious question - I am long out of touch with language design and practice - which currently used and popular language/compiler/optimizers have solid support for BCD and financial arithmetic?

    sPh

  • by satellite17 (816105) on Thursday August 21, 2008 @09:08PM (#24698719) Homepage

    how many PCs though.

    how much space do those PC's take up? How much power do they consume?

    Back in the day you had room sized mainframes, sucking up loads of power, sat in big expensive air conditioned data centres. Now you've got room sized server racks, sucking up loads of power, sat in big expensive data centres.

    I can guarantee that whoever it is you bank with runs all of their mission critical stuff on a mainframe (and you should be glad that they do). My company are spending over $0.6 billion over the next few years to completely rewrite all of our core systems. Not because the systems can't cope with the demand put upon them but because the software is showing it's age and isn't flexible enough to change as quickly as the business needs it to (and because if there is a piece of technology that's ever been sold we've probably got two of them sat in each of our data centres). Are they going to be running on Windows? err nope, how about Linux? nope. will there be an Intel processor in the box that runs all this stuff? Not a chance. Big iron all the way.

    Of course sat around that will be a bunch of web servers running web services and UIs for the users. Those are the machines that will be running the VMs and Java / .net apps that the GGP is talking about. and I'll be the guy writing that Java / .net software.

    I've sat on both sides of the fence, started my career as an admin on a mainframe, now I write software using the new fangled stuff. both of them have a place. I'm only 35 but I'd be surprised if the mainframe disappears before I retire

  • by coryking (104614) * on Thursday August 21, 2008 @09:45PM (#24699109) Homepage Journal

    It is amazing how few people realize how much of our society still uses steam. You forgot geothermal, and some forms of solar plants.

    Dont forget how pretty much any dense urban area is heated by a very large steam boiler and a large network of steam pipes. It isn't just a special effect in movies... those rising steam clouds from manholes really do come from buried steam pipes (though they really shouldn't be leaking steam).

    Steam is where it is at baby! It came before computers and will probably outlast them in the future.

  • by coryking (104614) * on Thursday August 21, 2008 @09:48PM (#24699139) Homepage Journal

    I find it charmingly cute how so many people think how google does it's servers is the end-all-be-all of technology design.

  • by evilgraham (1020325) on Thursday August 21, 2008 @10:01PM (#24699335) Homepage
    And I cannot stress how much you should be glad that your paycheck goes via a bank that runs its core systems on a mainframe instead of relying on your fuckwitted opinions as to how to implement data processing in a robust and scalable manner. Write a powershell script about that motherfucker!
  • by Temkin (112574) on Thursday August 21, 2008 @10:02PM (#24699337)

    My Dad was a mainframe operator when I was a kid. We're talking early 70's here, but he actually went all the way back to the IBM 1401. I've always had a fondness for the beasts, but no experience with them. Therein lie the problem. They're not at all commodity iron. Linux came into existence because commodity equipment became powerful enough to host such an OS. That cannot be said of z/OS. It simply doesn't run on anything I'm likely to find on sale at Fry's.

    How does one gain employable skills with untouchable hardware? (Note: I don't consider Hercules to be a solution. Where's the software?)

  • by DesScorp (410532) <DesScorp@NOsPAm.Gmail.com> on Thursday August 21, 2008 @10:29PM (#24699565) Homepage Journal

    Dinosaurs are extinct. IBM mainframes are more like alligators or crocodiles or sharks... mostly unchanged from, and still closely related to, it's dinosaur-era ancestors, but still alive because it's so effective at what it does. Like those animals, mainframes still are the undisputed ruler of their part of the kingdom.

    When we're old... hell, when we're dead... we'll likely still have something like Slashdot, with people saying "the mainframe will die any day now".

  • Nuclear and Steam (Score:5, Insightful)

    by DesScorp (410532) <DesScorp@NOsPAm.Gmail.com> on Thursday August 21, 2008 @10:41PM (#24699661) Homepage Journal

    "It is amazing how few people realize how much of our society still uses steam. You forgot geothermal, and some forms of solar plants."

    Yup. Back when I was in the Navy, and I got to my first ship, a nuclear carrier, I thought nuclear power was this gee-whiz technology; if you don't know any better, you'd be inclined to think that "nuclear power" is turning those propellers... via protons, electrons, ray-guns, something sci-fi like that. When a nuke machinist mate explained how it really worked, I was kind of shocked. Basically, all we had was a steam engine, where the heat came from a reactor instead of coal. Same process, just a different heating fuel. Since those days two decades ago, I've become fascinated by just how much "advanced technology" that we use is really nothing more than barely improved methods our ancestors used. Jet engines? Nothing more than prop engines with the fans on the inside and some ignited fuel in the exhaust. Ultra-modern rifles like M-16A4's and AUG and the L86? Working from the same priciples as rifles hundreds of years old. Hell, car engines are noting but a hunk of iron with a series of explosions in them.

    Technology most of the time is really nothing more than a machine that takes advantage of some principle of nature, and is often very, very simple at it's core.

  • Young mainframes (Score:2, Insightful)

    by roscaf (1282104) on Thursday August 21, 2008 @10:42PM (#24699671)
    I'm 24 and work in the banking and insurance industry. I spend most of my day looking at green text on a black screen and its not going to change anytime soon. We have two big hulking IBM zseries mainframes running batch jobs all night. We also have a good few servers running unisys, unicentre and techscheduler. I know by far I prefer OPC running on the mainframes, if something breaks its just a bit of bad code or input from inhouse. The hardware itself just never gives any trouble. The users don't care what is running on the background, we have csi's running against cics sessions so all they see is a nice little website with no clue what going on in the background and they shouldn't care anyway. Noones going to go to the expense of replacing all the cobol in the background as long as IBM keeps developing and supporting mainframes. They just work.
  • by roscaf (1282104) on Thursday August 21, 2008 @10:50PM (#24699733)
    Get a job in a bank or insurance company. They'll train you in and you should be up on your own as an operator in about a year. Its really not to complicated. Only cavet is its mostly shift work, people don't tend to last long at it and don't stay with it for more than 10 years unless they really love working nights. The trick is to get good enough as a mere operator to get into consulating, thats where the real fun stuff is and the money
  • by SanityInAnarchy (655584) <ninja@slaphack.com> on Thursday August 21, 2008 @11:34PM (#24700213) Journal

    How about a design where you have three CPUs, each running the same software on the same data, and if one gives a different answer, that CPU gets taken offline and support paged automatically to replace it?

    Build it at a higher level. Three separate PCs, each running the same software on the same data, and if one gives a different answer, the entire machine gets taken offline and support paged.

    The difference is, three PCs can be had for less than three thousand dollars, new, even with monitors and such. How much will one mainframe cost you?

    How about a design that lets you run applications 24 hours a day, 7 days a week, with no downtime required for system upgrades?

    Does Google qualify? How about Amazon?

    There are areas where mainframes eat Unix systems for lunch.

    Only if there's an irrational need for it to be exactly one machine.

    Which, if it is, what happens if, say, that building explodes?

    Disclaimer: I work for IBM

    I'll add a disclaimer, too: I work on a project which is currently deployed via Amazon EC2.

  • by SoupIsGoodFood_42 (521389) on Friday August 22, 2008 @12:09AM (#24700541)

    Well, an old prop and a jet engine are quite fundamentally different, as piston engines are still quite different to turbines. Of course, all turboprops, jets, and turbofans are based on the same turbine principals.

  • by BBCWatcher (900486) on Friday August 22, 2008 @12:19AM (#24700635)

    And scaling up a single mainframe gets exponentially more expensive; the price buying more commodity servers stays constant, meaning a linear cost of scaling.

    Why do IT people (I'm assuming) make such lousy economists?

    Think about it for just half a second. If you want to double the transactional capacity ("throughput") of your mainframe, you turn on more processor(s) inside the same box. (It's almost always inside the same box. A single mainframe can have massive capacity.) And you only do so when the mainframe is 100% busy for sustained periods, which it gracefully handles by the way without choking. You have zero reconfiguration to do to hardware, software, or applications: it's "on tap." (In fact, the machine itself can provision itself nowadays.) This is very cheap: doubling costs way, way less than the initial allocation. Also, up to 32 machines can share memory and operate as one, so if you are unusual and hit a single machine limit, no problem. It's only past 32 that you resort to partioning, traditional clustering, etc. -- and you've still got a lot more weapons at your disposal.

    If you want to double your actual transactional capacity with highly distributed servers, you...well, it may be impossible. You better hope you have highly segmented and partitioned work for those servers to do, and that it is extremely well balanced so that it fits into little server buckets. The burden is mostly or entirely on you, the application developer, to figure that out -- and that's horribly expensive. (Because the work never is balanced, you have to install a bunch of servers that don't run continuously at near 100% busy, so you get less real-world performance out of each processor anyway.) But at the very least you have to more than double the number of boxes. And you have a lot of knobs to twist and turn to get your work settled into its new, large number of machines, so you better hope you don't need that extra capacity NOW. (Can't process those credit card transactions during a spike in demand? Sorry about that -- I guess your credit card company will just have skip collecting those millions of dollars.) And you get to hire and pay some more people to install, configure, and maintain those extra boxes. You also get to find more space in your data center (if you have it), consume more than double the power (if you have it), and run the air conditioning more than twice as hard (if you can). You pay Oracle, Microsoft, et. al. at least double, too. (That's not how mainframe softwre works: there are strong price curves, not lines.)

    Fortunately there are some IT-economists in the world who understand this stuff.

  • by Animats (122034) on Friday August 22, 2008 @01:21AM (#24701123) Homepage

    IBM once made a desktop mainframe, the PC/370. You could run VM on it. But that was in 1985. Since then, they've avoided offering low-end mainframe compatible machines. There's no reason IBM couldn't offer a 1U server that runs zOS for $2000 or so, but they don't. Remember, most of the software was designed to run on machines well under 100 MIPS.

    As other people have pointed out, IBM-type mainframes do virtualization right. Virtualization on x86 is a hack and an afterthought, even with the newer hardware support. x86 virtualization with VT hardware creates a virtual machine that doesn't look like a bare machine with VT hardware; the virtual machine has no "ring -1". VMware actually patches code on the fly to work on older x86 hardware, which makes VMware very complex and vulnerable to bugs. The mainframe people don't have do that. On IBM-compatible mainframes, the virtual machine can look just like a real machine; you can run VM under VM under VM, and it works fine. About ten deep, it's too slow to be useful, but it works. This is good for stability.

    For historical reasons, PCs have a primitive I/O architecture. The "bus" concept came from the days when the peripherals and the memory were really on the same bus. That hasn't been true for decades now, but the architecture is still set up as if it was, with peripherals seeing physical, rather than logical addresses. In mainframes, there's an I/O MMU, memory protection between the peripherals and memory, and there's a channel architecture which standardizes how peripherals talk to the computer. PCs are still stuck in the "each peripheral has its own device register layout" era, which is why we have so much trouble with drivers. The "device register" and "bus" concepts are so deeply embedded in PC thinking that FireWire, which is really a local area network, was designed to emulate a bus with device registers.

  • by Tyrannicalposter (1347903) on Friday August 22, 2008 @01:22AM (#24701131)
    a dailywtf.com story in the making.
  • by ToasterMonkey (467067) on Friday August 22, 2008 @02:27AM (#24701529) Homepage

    The difference is, three PCs can be had for less than three thousand dollars, new, even with monitors and such. How much will one mainframe cost you?

    Are we counting the effort your team put into making these PCs work reliably in parallel, and the orders of magnitude more complex a cluster of discrete PC's is? Are we counting all the communications and storage networking infrastructure, and staff to support a cluster of PC's?

    Only if there's an irrational need for it to be exactly one machine.

    Obviously, where there is a single point of failure, you get a backup.
    Mainframes are no different. A DR plan for a mainframe doesn't say "move the smoldering remains of our only mainframe to the alternate site and call tech support." That's a silly notion, that mainframes repel each other somehow, or cut the heads off other mainframes so there can be only one. ;)

    Cluster of PC's > Mainframe is a flawed argument.
    You might as well say buying a couple quarts of oil is better than going to Jiffy Lube.
    You're shifting the integration work onto yourself. Even if someday you can just roll a giant PC cluster out the box, fully integrated, with the same features a mainframe provides, I think you'll find that the overall cost differential will not be very high. Then you have to figure out how to make them do work.

    I'll add a disclaimer, too: I work on a project which is currently deployed via Amazon EC2.

    So now you're talking about leasing time/resources on someone else's cluster environment, skipping the infrastructure ENTIRELY, so we're left with the "make it do work" part.

    Now, I'm not trying to tell you a mainframe is cheaper than just three PC's, even after all is said and done, it'll probably cost more. If you look at the resources a mainframe or large integrated system provides, it would take more than a few PC's to match though. Back to DR for a sec, considering the infrastructure to support a good sized PC cluster, how would that affect your DR planning?

    See, there are times when buying a couple quarts of oil is more appropriate, and times when going to Jiffy Lube are more appropriate ;)

  • by Guy Harris (3803) <guy@alum.mit.edu> on Friday August 22, 2008 @04:46AM (#24702287)

    In the 90's, the AS/400 went from a 32-bit CISC processor to a 64-bit RISC processor.

    If this were Intel, we would have had to go through the code looking for bustage (like we did when Windows' wParam went from 16 to 32 bits). This being an AS/400, we didn't even have to recompile! Just copy everything to the new system; on first execution, programs are converted to 64-bit opcodes.

    ALL AS/400 (iSeries, System i) programs have been 64-bit since the mid-90s; no programmer intervention required.

    ...because the compilers available to application developers generated code in a very high-level pseudo instruction set that the low-level system code translated to native code on first execution. The high-level code was (usually) kept around, so that on the first execution on a RISC system it could be translated to the (extended) PowerPC code the RISC processors run.

    The System/360-to-z/Architecture machines didn't do that. 32-bit data/24-bit address programs stay 32-bit data/24-bit address programs even when run on 32-bit data/31-bit address or 64-bit data/64-bit address machines, and 32-bit data/31-bit address programs stay 32-bit data/31-bit address programs even when run on 64-bit data/64-bit address machines.

    However, the processors can, at least, still run those programs (just as, for example, x86-64 processors can run IA-32 programs, or SPARC v9 processors can run SPARC v7 or SPARC v8 programs, or..., OS permitting).

Those who can, do; those who can't, simulate.

Working...