IBM's Mainframe Dinosaur Turns 40 384
theodp writes "According to an SFGate.com article, PCs were supposed to kill off the mainframe, but Big Blue's big boxes are still crunching numbers, posting sales of $4.2 billion in 2003. First unveiled on April 7, 1964, the IBM mainframe computer celebrates its 40th birthday this week with a sold-out party at the Computer History Museum." The SFGate article also reveals: "Doug Balog, an IBM vice president, noted that 70 percent of the world's data are still housed in mainframe computers."
Never in a million years... (Score:5, Funny)
If it aint broke..... (Score:5, Insightful)
Well, there is a reason you still see COBOL jobs being posted from time to time. The IBM mainframe architecture was well designed and well implemented and to quote an oft used phrase: "if it aint broke, don't fix it".
Of course they have made some improvements over the years, but these things are going to have a mighty impressive return on investment over the course of their lifetimes. Much more so than your average desktop PC which (if your running Windows) needs (is required) to be replaced every couple of years or so.
Re:If it aint broke..... (Score:5, Funny)
Re:If it aint broke..... (Score:5, Interesting)
And IBM takes yet another spin on that. Their view is "if it breaks, figure out why and change it so that it won't break that way again". Mainframes are very powerful and have great I/O, but their greatest strength is reliability. They have tremendous failover capability, can hotswap components so that they can keep running as they're repaired or upgraded, and are instrumented so if one does fail the cause can be traced and corrected. No, make that the cause will be traced and corrected. Whenever an IBM mainframe fails, anywhere in the world, IBM will hear about it and go to the trouble of a post-mortem.
Re:If it aint broke..... (Score:5, Interesting)
What does the "Z" in Z-series stand for?
Zero Down-time
Re:Two words: Murphy's Law.... (Score:3, Informative)
Even smaller IBM servers (like AS/400) have built in UPS. So unplugging for a short period of time won't hurt it.
Besides you can find even PC servers with redundant, hot pluggable power supplies. In mainframe every piece of hardware is hotpluggable including processors.
Re:Two words: Murphy's Law.... (Score:4, Interesting)
- I'll just IPL (reboot) the test partition to test out some changes Ive made. Opps, wrong partition.
- I'm on this test partition with this new OS ready for testing. Hmm this security database copy tool appears to corrupt the database. I'll take diagnostics and send the results off to IBM. Oops Ive just copied onto the live production database and corrupted it, and now everything is failing security checks. I cant switch to the backup database cos I cant work out which security message is the one for the database switch.
- I'm a dumb bulding subcontractor, I'm in the basement drilling into walls, but I dont want to electrocute myself, so I'll go and throw that big switch with the red mnessages over there.
- I'm an even dumber contractor, some idiot has thrown the main 3 phase power switch and walked off, so I'll just throw it back again. BANG!!
- The power has been rather unreliable of late, and the UPS has been continually taking short 5 minute loads whilst the generators kick in. Now the power has gone for the 10th time this weekend, and the UPS has run dry, and the generator cant kick in in time.
It is possible to bring a mainframe down, but it requires stupidity, superuser proviledges, access to the poser supply, or a large axe.
Re:If it aint broke..... (Score:3, Interesting)
I have always wondered why modern managers don't care about failures - resorting to re-boot and cross fingers.
IBM goes after failures hammer and tongs, because DATA CORRUPTION is not acceptable at any price.
Makes me wince thinking of Financial Institiutions on all MS - who cares about inflight I/O's, memory 'leaks', and glitches.
Re:If it aint broke..... (Score:3, Insightful)
That is because most managers have never made an effort to compute what it would cost them if they should lose their data, and also do not have a clue what a downtime costs them.
I have worked with someone who had done these figures, and he was never happy with downtimes, to say the least.
Re:If it aint broke..... (Score:5, Interesting)
While I am also a fan of IBM mainframes (we've had numerous mainframes that have had up-time measured in years), in all fairness, they have to be replaced periodically as well. Not because they're no longer capable of doing the job, but because after a while, IBM will take them "off maintenance", or will take an old rev of the OS (or VTAM, or NCP, or CICS) "off maintenance" and it just turns out that the current supported level will not run on your box. IBM has to make money, too. And any company that can afford a mainframe and needs one to run its core business would no more run an unsupported OS than you would go to work without your pants. So maybe the upgrade cycle isn't as short as PC's, but I'd bet you have almost no chance of finding a 15-year-old MVS box running any business anywhere.
Re:If it aint broke..... (Score:4, Informative)
The IBM mainframe architecture was well designed and well implemented...
Indeed. In fact, there are many now-old innovations in it that "newer" technologies still don't completely get, like a true virtual machine architecture. Such capabilities, relatively trivial to add if designed into the hardware from the beginning, are painful and inefficient to emulate if not.
Then again, I don't miss hex-based floating-point!
Of course they have made some improvements over the years...
One of the more amazing at the time that I saw was a workable subset implemented in the '80s on a PC card. It turned an early IBM PC into a desktop mainframe for some applications.
Re:If it aint broke..... (Score:3, Informative)
I remember some COBOL developers in the mid-90s using MVS on some specialized PCI cards. I used to have a bookmark to the vendor that made them, but it's long gone now. Instead, how about running ES/390 in an emulator [conmicro.cx]? Dust off those JES commands and have some fun IPLing on your PC. Now if only Storagetek made USB cables for the
WebSphere (J2EE) and DB2 on mainframe (Score:4, Interesting)
I did some work for a large payroll company, and this was the platform IBM sold them for running mission critical payroll processing for its thousands of customers.
This isn't about legacy application as much as it is about consolidating clustered applications into an easier to manage platform. Believe it or not, you can still do state-of-the-art software development despite the physical housing being a mainframe.
We did all the software development on the PC. The mainframe was simply the deployment destination. This is one advantage of the J2EE architecture. This also ruled out .NET, as Windows didn't offer the stability that Linux offered on the mainframe. However, we did happen to use Windows on the PCs in order to be able to use Rational Rose. Barring Rose, which isn't needed in deployment, our development architecture was completely compatible with Linux.
From a J2EE perspective, this eliminated the need to manage clusters in operation, as well as to develop for them. Clustering, despite its raves in the news, has a lot of production related issues that the mainframe solves. This is part of IBM's marketing pitch.
Re:COBOL (Score:5, Insightful)
I told them that with two weeks and a good book, I could be as fluent in COBOL as any of their engineers, but that wasn't good enough.
You may think wthat's what you told them. What you really told them was:
Re:COBOL (Score:5, Insightful)
Re:Programming is simple....Optimizing is hard.... (Score:3, Insightful)
I know it took me about a year to become as good as some of the veterans at coding for large business machines at the company where I work, and I was proficient in a wide variety of different programming languages before I applied there.
Re:COBOL (Score:5, Insightful)
Big iron I/O rocks... (Score:2, Insightful)
Re:Big iron I/O rocks... (Score:2, Funny)
We had an IBM machine big enough that I could walk inside it. Ah, the good ol' days.
Re:Big iron I/O rocks... (Score:5, Funny)
Ahhhh! So YOU were the bug.
-m
Comment removed (Score:5, Funny)
Re:IBM management said that did they? (Score:4, Interesting)
Dan East
Re:IBM management said that did they? (Score:3, Interesting)
Re:IBM management said that did they? (Score:5, Informative)
There are quite a lot of such obscure applications out there (especially in the earth and space sciences) that gather titanic amounts of data. Even if Google cached all five billion web pages, and each web page was a megabyte (which is probably way overestimating), that's 10 petabytes of data (5 petabytes each for the pages and the cache). Now think about the thousands of mass-data-collecting computers there are out there, that (between them) archive more data than that every day.
Re:IBM management said that did they? (Score:3, Informative)
But it's not. They keep a cache copy of almost all the HTML and other text, and thumbnails of all the graphics.
Chris Mattern
Support is easier on a mainframe. (Score:5, Interesting)
From The April 98 Byte: (Score:5, Interesting)
Re:Support is easier on a mainframe. (Score:5, Funny)
Re:Support is easier on a mainframe. (Score:2, Funny)
Re:Support is easier on a mainframe. (Score:3, Informative)
For those who don't know what a PDP-11 is and are afraid to ask, it's a minicomputer (mainframe, mini and micro, a desktop is a micro) from DEC.
PDP-11 FAQ [village.org]
A different kind of mainframe (Score:5, Interesting)
I personally don't think mainframes will be gone... ever.
Re:Not gone, just smaller.. (Score:2)
Ohh, wait..
Re:Not gone, just smaller.. (Score:3, Insightful)
As far as tapes, well, you don't normally mount tapes like the old days with reel to reel spindles. Those things weren't nearly as fast as a modern DLT or AIT system. A modern server PC can easily handle a handful of drives operated with very large robotic library systems. You don't need "operaters" anymore, man.
I do bel
Re:Not gone, just smaller.. (Score:3, Interesting)
With regards to the printers: 128 at the moment via local connections (though 127 sharing 12Mbps of bandwidth, if you include networked postscript printers, effectively unlimited) Terminals: serial (atm, just 2, though I have a couple of multi-port pci serial cables), network(effectively unlimited, and already has netbooted machines (sparcs and x86)), co
Re:A different kind of mainframe (Score:5, Funny)
>the actual guts of these computers have actually improved with the times
God, yes. You hardly ever see iron-core memory anymore, and punch cards are being phased out right and left.Re:A different kind of mainframe (Score:3, Interesting)
I'll keep my pointies and clickies, thanks.
Consequently... (Score:5, Informative)
Because PCs was wrong (Score:5, Interesting)
Mainframe + dumb terminals:
Code executes in one place (one machine to maintain from a software viewpoint). Code 'lives' with the data.
Collaboration/groupwork/etc is a no-brainer. "Brenda bring up invoice #43223 and blah blah blah".
Software is protected from users (for the most part).
PCs + Fat/thin Clients:
Code excutes all over. You wind up with versioning/dependency hell. It's a bitch to administrate. Just when you think everythings good, some jackass installs a swimming fish screensaver and you're back to level 0.
Data winds up in multiple, disjointed, locations. Bleh..
Where I work we installed, and still support (and will for a decade past the official HP EOL date) HP 9000 series mainframes. I mainly deal with moving that stuff to the PC world, and I can tell you, lifes a whole lot simpler when you dont have to worry about what version of the OS, etc, etc, etc is running on the client machines..
We're looking hard at Windows Terminal Services - essentially a modern day mainframe implementation, complete with GUI. Or we could go multiple X sessions, but our customers aren't to thrilled with the idea of *nix..
Windows Terminal Services is a joke (Score:5, Informative)
Thin Client Windows has been a nightmare, and it's only getting worse. One of the original incarnations, WinDD hosted by a Tektronix-modified version of Windows NT 3.5, wasn't so bad... Windows was simpler back then. But all of the "ease of use" and "zero administration" crap Microsoft and Citrix have built up since then has made thin client Windows a miserable beast to deal with. I know many administrators who swear a building full of plain PCs and a good Norton Ghost setup is easier to maintain.
tad more... (Score:2)
Re:Windows Terminal Services is a joke (Score:2)
I know at least 1 site where term services is being used pretty effectively, even over the internet. It's being used for administration and technical tasks rather than end-user applications, but it seems to work well -- not much lag/net load, no issues with multiple sessions (up to about 6, a mainframe replacement this is not).
Performance is much better than with VNC.
If it has a failing, it's that the rules for when a session times out are kind of inscrutable and result in reconnects when a session is le
Re:Windows Terminal Services is a joke (Score:3, Interesting)
Re:Because PCs was wrong (Score:4, Interesting)
Doing everything over dumb web browsers is okay and all, but it's not very user friendly for a lot of applications. In order to bring web apps up to the usability of a traditional application, you're still dealing with versioning problems on the clients, because the browers will have to become a lot smarter. Java can overcome many of these problems if you can write your apps in it. But again, what version of java you got on your clients? Where is the code executed?
In a perfect world, there's on server and all the clients can run the apps without worries about versions. Unfortunatly we don't live in one.
If you run a tight shop, and don't allow people to install screen savers that will bring you to level 0 (incidently, that same indivual could do a lot more damage if untrusted and left to run amuck in your mainframe..) you can actually put together a decent system using distributed servers versus a mainframe.
In my opinion, it's all the way you manage the system. You can quite easily run a terrible shop whether you run big iron or PC servers.
Re:Because PCs was wrong (Score:5, Informative)
biased quote? (Score:5, Insightful)
Is it just me or is that a bit of a biased quote? Its kind of like Steve Jobs saying that "Apples are the fastest computer on the face of the planet", or Bill Gates saying that "Windows is the most secure OS in the world". These statements may or may not be true. Studies may be done to determine the validity of the claims, but I would argue that ultimately most of the world's data is tied up in Girls Gone Wild DVD's. The point is that the makers of the claims have a bit of a personal stake in the claim, making them slightly more apt to being taken with the obligatory salty grain.
Re:biased quote? (Score:3, Insightful)
Where do you think tax, banking, airline and similar data is kept?
The other 30 percent (Score:5, Funny)
70% of world's data housed on mainframes (Score:3, Funny)
The other 30% is porn and cookies.
They'll be around forever (Score:5, Informative)
Lots of money to be made in desktop-mainframe connectivity.
Linux not mentioned? (Score:4, Interesting)
Has that number dropped off?
Re:Linux not mentioned? (Score:4, Informative)
Re:Linux not mentioned? (Score:5, Interesting)
Major differences were required in the kernel to support a scalable Linux at that level which meant source code compatibility wasn't always reliable. This meant that even though it was Linux, you still had to have a core team trained up on the intricacies of the mainframe system and programming and so it is still costly (you may need 5 people to maintain the same # of machines that a mainframe can handle with just 1 operator, but the cost of salary for that 1 mainframe specialist may be close to 5 times the cost of the average web farm maintainer which is often just a kid in college happy to make triple minimum wage).
Additionally many of the early Linux mainframe deals were for hosting services where the mainframe functioned as a place to store many many many Linux virtual machines, the end effect of that being that it didn't reduce over all system maintenance much except on the hardware level. The markets where many many many linux virtual machines are needed are often served fine by smaller hardware in bulk that can be updated regularly over time.
It's not dead, but it definitely didn't live up to expectations that IBM set.
Linux is still better suited for the mid-size and smaller hardware world. May change but IBM expected it to change very fast. Plus, 15% of new mainframes is not that large of a number. Most mainframe sales now are into existing mainframe users, it is not a growth market.
Re:Linux not mentioned? (Score:5, Informative)
That said, I've been talking to IBM about Linux on the mainframe recently and while I don't have an actual figure handy, I wouldn't be surprised if the number your source cited were true, and in fact there may be even more movement in the Linux-on-mainframe area than that figure suggests.
IBM is marketing Linux on the mainframe primarily to existing mainframe customers who want to further leverage their investments there. Remember that mainframes tend to be very modular and upgradeable ... you need not replace the thing to see performance gains or new functionality. You can just buy some new parts.
So IBM is selling a version of Linux that will run under zVM, its mainframe virtualization technology, as well as hardware modules that are basically PowerPC G5 units you can add to the base hardware for the explicit purpose of running Linux. (I don't think you necessarily need the add-on modules to run Linux, I just know that they're available.)
This doesn't really have any benefit at all if you're running a compute cluster or any other application where the Linux boxes are running at high utilization all the time. The main purpose for this is consolidation of lightweight servers. Let's say you have a farm of a hundred Linux Web servers that mostly sit around idle, and the heaviest lifting they need to do is to hand off transactions for processing in the database on the zSeries mainframe. IBM suggests that you instead roll all those servers into virtual machines on the mainframe itself.
Note that we're usually talking about a mainframe that's already in production use, here. You don't need to wipe your mainframe and start over with Linux. You can run Linux instances and z/OS instances at the same time. You gain the following advantages:
From my understanding, IBM doesn't really have a whole horde of customers yet, but I bet a lot of mainframe customers are evaluating the option.
More information on this, as well as mainframe topics in general, in last week's InfoWorld: here [infoworld.com], here [infoworld.com], and the full PDF special report on mainframes here [infoworld.com].
Re:Linux not mentioned? (Score:4, Informative)
The S/390 port of Linux will run natively in a zSeries logical partition (or LPAR -- a builtin virtual machine facility). You can define between 15-30 LPARs in your complex, regardless of the number of physical processors that are present. I run twin z/OS images and one SuSE Linux server on my single-processor system, without the benefit of z/VM.
There is no "PowerPC G5 unit", though you may be referring to a so-called "IFL" processor. This is a CPU that is only licensed to run z/VM or Linux. Since z/OS is charged on a per-CPU basis, you can save on software costs if you purchase additional IFLs instead of full-function processors. (This is only a licensing trick; both types of processor still run S/390 code.)
PC based systems aren't up to the task. (Score:5, Informative)
I have 75 iSeries (As/400) that I oversee. You want to know how much time I spend per week checking up on them? Only an hour or so. I receive reports from the machines when they have problems. If one has a fault it is usually hardware and rarely does the downtime pass a few hours.
Meanwhile the network group (read : uses PC based technologies) is always fixing something and has 5 people dedicated to it compared to two for the iSeries boxes. That doesn't count the PC-support group which supports desktops...
We have 3 mainframes as well, some of the code from these machines has been in use since the early 70s. Some of the code migrated to the iSeries with little but header changes.
But the best, the iSeries has been on 64-bit PowerPCs natively for 10+ years. Didn't have to recompile or change 99% of our code to do it. How long has the PC base world been struggling to get there?
Re:Free clue for you (Score:3, Informative)
He never said AS/400 ws a mainframe. He talked about both mainframes and minicomputers. In fact, if you look at his post again, he said his business has 75 AS/400s and 3 mainframes.
And for those that don't already know this: even a big Unix server is still a Microcomputer. Takes more fault tolerance and funky system architecture than what a Sun has to be called a Mini.
Which brings up the question: is an HP/Tandam NonStop Himalaya a mini or a mainframe?
"70 percent of the world's data" (Score:4, Informative)
Re:"70 percent of the world's data" (Score:2, Insightful)
Re:"70 percent of the world's data" (Score:3, Interesting)
Obso1337 (Score:5, Funny)
- The Devil's IT Dictionary [isham-research.com]
SPF/PDF (Score:5, Interesting)
and long after no one cares who billgates was, there will still be Big Blue Iron.
oh yeah, BSD Lives!
Re:SPF/PDF (Score:4, Interesting)
I remember back around '90 - 14 years ago that in diaglog manager I could create a complete database table update UI with all crud functionality (create/rename/update/delete) in about 150 lines of simple rexx code. That's with zero reuse.
Then I encapsulated that, it only required about 40 lines of actual code.
I've since worked in a lot of java shops and am accustomed to see a thousand lines of code for the same purpose - and everything is written from scratch.
Well, MVS & ISPF were pretty far behind in some ways, but Rexx & Dialog Manager are still ahead of java & j2ee in some ways. And that's from 15 years ago.
Mainframe vs. Supercomputer (Score:2, Interesting)
Re:Mainframe vs. Supercomputer (Score:5, Informative)
The simplest way to think of these two classifications is that
- "Supercomputer" refers to processing speed and is defined differently in different contexts (i.e. Apple calling its G4 400 a supercomputer because of an outdated US Customs document).
- "Mainframe" refers to large systems that many users are going to use at the same time, typically via dumb terminal interfaces. Most importantly, mainframes have IO architectures which blow any desktop/workstation out of the water. A good mainframe can be talking to 500 terminals while printing 1000 different bank statements to 100 different high-speed line printers without even breaking a sweat.
Hope this helps. Any other fun definitions to add?
Re:Mainframe vs. Supercomputer (Score:2)
Re:Mainframe vs. Supercomputer (Score:5, Informative)
General purpose machine.
Tons of IO bandwidth.
Substantial processing power.
Highly redundant and fault tolerant.
Flexible and scalable architecture.
Their OSes are very secure and support thousands of users.
Supercomputer:
Specialized scientific machine.
Tons of memory and/or interprocessor bandwidth.
Loads of processing power, especially vectors.
IO speed may not be important.
Redundancy and fault tolerance not as critical as with mainframe.
Architectures tend to change more frequently.
OSes not geared for business use.
Re:Mainframe vs. Supercomputer (Score:2)
Re:Mainframe vs. Supercomputer (Score:2, Informative)
Supercomputers are all about speed. Large size is optional, but it must be able to do at least a billion floating point ops per second.
Mainframes are always huge, and are all about reliability. They run great, because the current ones were designed in the 1970s, and have had nothing but bug fixes since t
Re:Mainframe vs. Supercomputer (Score:5, Insightful)
Mainframes are always huge, and are all about reliability. They run great, because the current ones were designed in the 1970s, and have had nothing but bug fixes since then.
A modern IBM S/390 zSeries mainframe may have an overall design from the 1970s, but its individual components (CPUs, I/O controllers, etc), as well as the thruput of the busses is very modern. A recent mainframe could easily benchmark in the multiple gigaflops range of raw performance, but that isn't the point. Mainframes are all about moving important data reliably (and, if possible, fairly fast). A credit card company isn't going to trust a Cray and a scientist isn't going to do his simulations in COBOL on an IBM S/390.
70%? (Score:5, Funny)
They obviously haven't seen my pron collection!
Re:70%? (Score:5, Funny)
Flying Mainframes (Score:4, Informative)
Depressing sales figures. (Score:3, Funny)
Re:Depressing sales figures. (Score:2)
No, they sold three. The rest of the money came from Consulting Services.
Ah, Engineers (Score:5, Funny)
The IBM mainframe computer celebrates its 40th birthday this week with a sold-out party at the Computer History Museum
Yeah, I'll bet that's going to be a real barn burner
Mainframe older than that (Score:5, Informative)
I feel ancient..... (Score:3, Interesting)
Tired of computing and hoping for a less-stressful retirement.
Interesting... (Score:5, Interesting)
They TRIED to convert it to a more conventional system, but they couldn't, due to the fact that no database on earth could handle the sheer number of records.
Impressive, no?
Re:Interesting... (Score:2)
That's a very odd definition of conventional...
Mainframes are as conventional as you can get.
They're also old school beasts with more raw data processing power than you can dream of on a pansy PC or ordinary unix-like system.
Re:Interesting... (Score:3, Interesting)
I'm sure it's a nice solution - but the reason for it probably has more to do with reliability than performance.
On big unix hardware these days (i'm talking large IBM/Sun/HP clusters) databases typically sling *billions* of rows around. The cost / transaction is far lower than a mainframe, and in my experience they are far faster and more scalable.
However, they simply aren't as reliable either.
Silly (but original) joke: (Score:2)
four.. Three to hold it down and one to rip it's header off.
The real "problem" with mainframes (Score:3, Informative)
Mainframes are Turing Complete, so that any software can be made to run on them if the tools are built. Thus, things like limited-length file names can be transitioned to longer names in a way similar to how Windows allowed one to move to long file names. A mainframe could make an ideal web server because of its security and multi-processing capabilities. If this is the case, then why is it not done often?
Companies seem to have trouble doing this because of data sharing issues. They must keep using the old data while the conversion takes place to newer conventions. But this would mean having Java and PHP apps accessing data stored in the likes of IMS (navigational) databases. But this would mean one had to keep using IMS even after the conversion. (There are IMS-to-relational translation techniques, but they are hokey for the most part and it is tough to get decent normalization because of the different philosophies.)
Thus, the "problem" with mainframes is not the hardware, but the database conversion. The live data cannot easily be in two kinds of databases at once.
Re:The real "problem" with mainframes (Score:5, Interesting)
Alternatives to COBOL have existed since the 60's. PL/I is an excellent alternative. It supports literally everything that is any good in COBOL and gets rid of most of the COBOL crapola. The biggest reasons people have not switched is probably because they don't know any better and go with the idea that if it ain't broke, don't fix it.
As to reltaional databases, well - they are NOT a good alternative for many tasks that run quite well in the mainframes. The fundamental design objective of a relational data base is to expose any and all data to applications. In fact, this is diametrically opposed to what we really need.
Most data ends up archived at some point and from that point on we need read only access. This is not what relational database systems try to accomplish.
Another thing the wanna be replacement computers do not have is the Partition Dataset. We probably can build such a beast into Linux using loopback mounts or a variation thereof. But it is going to take a lot of work for reasons I'll describe next.
A PDS is tied to a set of applications and to a group of users. When you do a loopback mount of a file the system exposes the contents of the file to every user and application in the system. Thus every file in the directory becomes subject to tampering, either inadvertent or deliberate.
Meanwhile the contents of the PDS can be relied upon in much the same was as the contents of a tarball can be relied apon.
What this all boils down to is that the mainframe provides capabilities that are not found in alternative systems.
Re:Please explain (Score:3, Interesting)
A tape with the write enable ring / switch pulled off cannot be modified because the hardware it is mounted on checks for this. In a database with everything on-line a simple keystroke error defeats what you wish to accomplish.
Simply put - if I take my data off line then it does not matter how insecure the system is - you cannot access it.
The gist of what I tried to comment on is the v
Re:The real "problem" with mainframes (Score:4, Interesting)
DB2 was the second commercial database out there (following oracle by 1 year around 1983). It's been on mainframes since the very begining. I first starting working on relational databases in 1986 - and it was about 10 years before I finally began to meet a reasonable number of unix or windows developers with database experience. And oh yeah - I've gone through *hundreds* of resumes while hiring back in the 90s, so i'm not hallucinating here.
> If the applications used relational databases, then one could much more easily slowly replace
> COBOL applications with a more pleasant language of implementation in piecemeal.
Hmmm, on an IBM mainframe you've got rexx (like a simple functional version of python), c, java, pl1, etc. All reasonable languages. And they've been there for a while - I wrote C in MVS back around 1992, and Rexx back around 1990. They all talk to DB2. And btw, you can develop good systems with JCL & COBOL it is a little challenging, but not impossible. And I've seen COBOL systems that were far easier to manage and use than their modern counterparts. Of course, much of this has to do with the skill of the developers.
> A mainframe could make an ideal web server because of its security and multi-processing
> capabilities. If this is the case, then why is it not done often?
Reason #1: many mainframe shops are still running the software legacy from the early 90s. They don't have a linux lpar and old-timey protocols aren't ideal for this (often require expensive middleware). But for those organizations that set things up right, there's no real technical limitations.
Reason #2: simple economics. Web serves are the simplest applications out there - and it's awfully easy to deal with scalability & reliability through redundancy. They're probably the worst candidate for rehosting on a mainframe. Database servers, on the other hand, are good candidates.
However, in my experience the best candidates for hosting on a mainframe - are database standby servers. You can run a nearly infinite number of the things for nothing - since almost all are idle, and db2/oracle/sybase/postgresql/mysql/etc - all run just fine on suse/whatever linux on vm.
I don't understand (Score:4, Funny)
So, IBM sold three mainframes. What's the big deal, here?
"Mock Mainframes" use the philosophy (Score:5, Interesting)
(I especially like the Willow Rosenberg quote).
Back and Forth (Score:4, Interesting)
Think about it... Back when people used to actually, literally wire programs into old time computers... all that stuff still happens in that box on by your feet or on your desk. Thin abuout how many levels and how much duplication in task there is in a PC:
You have the microcode at the processor level which is really an analog to programs. But they aren't programs for you, the user. They are programs for the CPU's infrastructure. Then the RAM... It' all over the freakin' place. It's in the CPU, on the motherboard in various places, in your DIMMs, your video card, many periphs, etc... Then you've got the BIOS which is like higher level software compared to the microcode. It's a st of single purpose applications again. But not for you... it's for your hardware. And it interfaces with the OS at some point which (in many cases these days) takes over for the BIOS adding yet another layer of software.
This time, the software that the OS is, is partially for you and partially for your hardware. If you are strictly speaking kernel-wise, then it's pretty much a bridge between user space apps (shell) and the machine. Then you have your final layer of applications which ARE for you. But will it end there? No... you've got the network protocol stacks. This is the top layer of the multilayered cake that leads to the network.
But think about it. It's ALL THE SAME THING. Over and over again at different levels with slightly different purposes. So... at some point in time, all these PCs are going to be embedded devices, or wearables, or implants or entities providing even more layers. But when you peel the onion, you're still going to see THE SAME THINGS. Over and over and over again. And on top of all of that, you are going to see the shifts back and forth from centralized to de-centralized and back again. It's part of some cosmic imperative because if you think even eeper you see it mimicked in politics, communications technology (think old time TV vs. satellite vs. over the air digital vs. WLAN based PVRs), and even the automobile vs. mass transportation.
It's some kind of cosmic rhythm that pulses through the millennia like an ethereal rave...
Correction (Score:5, Funny)
should read:
Comment removed (Score:4, Interesting)
Needed: CICS for modern computers (Score:5, Informative)
CICS is a neat idea that deserves a new look. It's a "transaction processing OS". Think of it as an OS whose purpose in life is to run CGI programs efficiently. In its simplest form, each incoming transaction starts up a new program which reads the transaaction, connects to the database, processes the transaction, and exits, typically within a fraction of a second. The operating system is optimized for starting and running those transactions.
CGI processing under Linux is inefficient, and hacks like mod_perl are needed so that a new process isn't created for each transaction. One could do better. Transaction programs under CICS are started, run up to the point that they need input, and stopped. When a transaction comes in, a copy of the stopped transaction program is forked off, used to run the transaction, and terminated. So there's no way for data to leak between transactions. All transaction programs run in a jail, allowed to talk only to the database and to reply to their incoming message.
With better OS support for transactions, web servers could have a cleaner, faster interface for their transactions.
While IBM has the majority of the mainframe market (Score:3, Insightful)
At least two of the top four airlines in the US are still heavily using Unisys mainframes, for example. Those are based on the Sperry UNIVAC 1100-series boxes of the 1960's and 70's (a 36-bit architecture which is word-addressible, not byte-addressible) and an OS called OS2200 (or OS 2200), and many of them are still running applications software that was originally designed and written during that era (though it is constantly being modified in-house, of course).
As others here have said, mainframes are simply not the old coal-fired boxes that they are sometimes portrayed to be, certainly not on the hardware side of things. What they really are is a centralized server whose design is specialized around very high levels of reliability/recoverability and high levels of data throughput combined with the ability to serve applications to thousands of users with very low levels of system and communications overhead for each user action.
That makes them exceedingly efficient at what they do, not just large and expensive.
Also, while most of them tend to have some "stone age" elements on the applications software side, keep in mind that most of the older software tends to be found at the API level, not in the core of the OSes which support that API.
While application code on those boxes might be very old indeed, or at least based on very old software interfaces, the hardware and software platforms which form the guts of those mainframe boxes have been moving forward over the past few decades just as quickly in many areas as they have been in the desktop and smaller server world.
Part of the reason that such systems still exist is certainly tied to various economic factors like the difficulty of porting applications and such (when one has several million lines of code which is tightly tied to one's business rules, one doesn't rewrite that software arbitrarily).
However, some companies still use mainframes for another reason: they have a few applications which simply cannot fail if the company is to operate effectively. In some cases, even a small outage can cause cascading effects thorughout the company and cost the company millions of dollars. Or more.
My own experience is with major airlines, and they are one of the largest users of such systems in key areas, but financial entities such as NASDAQ have been using similar large systems for years because they need a very high level of reliability and recoverability.
I really think it's a shame that more people are not exposed to these types of systems in college so they can get some sense of what those machines are actually designed for (and what the hardware and software in those boxes is actually capable of).
While Unix, Windows, and Mac systems are ubiquitous these days, they simply do not define all existing computing architectures by themselves, nor can they effectively or efficiently handle all types of computing tasks. Not yet, anyway...
Re:DATUM not data (Score:4, Informative)
That's because you are the one that is wrong. Any and every dictionary I've ever seen has data as the plural of datum. Maybe no one is paying attention to you because they're tired of explaining it to YOU.
Re:DATUM not data (Score:3, Informative)
Merriam-Webster begs to differ: Etymology: Latin, plural of datum [m-w.com]
Although I don't think I've heard many people ever talk about datum either... maybe because it's always always plural. When was the last time you had only one piece of datum?
Re:DATUM not data (Score:2)
maybe because it's almost always plural
Re:DATUM not data (Score:2, Interesting)
A datum is a statement accepted at face value. Data is the plural of datum. A large class of practically important statements are measurements or observations of a variable. Such statements may comprise numbers, words, or images.
The word data is the plural of Latin datum, neuter past participle of dare, "to give", hence "something given". The past participle of "to give" has been used for millenni
Re: (Score:2, Funny)
Re:DATUM not data (Score:3, Informative)
data ( P ) Pronunciation Key (dt, dt, dat)
pl.n. (used with a sing. or pl. verb)
Factual information, especially information organized for analysis or used to reason or make decisions.
Computer Science. Numerical or other information represented in a form suitable for processing by computer.
Values derived from scientific experiments.
Plural of datum.
[Latin, pl. of datum. See datum.]
Usage Note: The word data is the plural of Latin datum, "something given," but it is not always treated as a plural nou
Re:DATUM not data (Score:5, Informative)
Re:haappy Biirthday Tooo you! (Score:3, Funny)