Slashdot Mirror
The Practical Value Of Mainframe Linux
Sun Tzu writes: "Just in case you're wondering what else to do with the mainframe in your basement, here's some useful information to help you prepare a proposal to management." The article is clear and candid, noting things like, "In some discussions the issue of the S/390's 'five 9's' reliability is brought up. However, IBM's 99.999% uptime claim is for clusters of mainframes, not a single system." And no, running 40,000+ virtual Linux boxes is not that practical. Still and all, I wonder how much an S/390 will cost in 3 years ...
Yes and no. The 40k copies is one of those unfortunate statistics that leaks out every now and then, but has no practical value in the real world. The fact that it can run 40000 is irrelevant. However, the fact that is can run many copies is relevant. 40000 wouldn't be practical. 100 concurrent copies, on the other hand, is both practical and useful.
"The invisible and the non-existent look very much alike." -- Delos B. McKown
Erm, I made it 5 minutes and about 15 seconds a year downtime.
Troc
Troc's dubious podcast and blog: http://www.trocnet.net
Umm. 99.999% uptime is 1 in 100000 downtime. This is 0.86 seconds per DAY, or more reasonably, about 5 minutes per year. This is imaginable for a permanently manned installation. Once every year or so, you could toleate the the operator having to manually switch off a malfunctioning CPU that had refused to failover gracefully, or remove a dodgy cable that was causing behaviour too unpredictable for the O/S to figure it out, or something of that order.
Still pretty impressive though.
Hmm, I make it 0.864 seconds/day, which is rather more impressive. Go check your sums.
Who's this us?
Please to not be speakink for me and please to be applying the following replacement expressions to your post:
s/any of us/me/g;
s/we/I/;
s/the average person/me/;
I don't know about you, but I read Slashdot, and I've had to work with mainframes and their care & feeding. (Not anymore, thankee goodness.) But I think you'd be surprised to find the number of IT/IS nerds around here who're happy to hear about something like this, and want to try it.
The nerds that Slashdot is news for are not just basement Linux hobbyists running MP3's on 133Mhz Intel machines.
That's the beauty of VM. When you log onto a VM system, your operating system is "booted up", using the same software programming techniques as if you were booting off the bare iron.
However, there are many facilities that VM provides that the native hardware does not provide. Things like inter-virtual-machine communication, etc. However, if you restrict yourself to only using programming facilities defined in "S/390 Principles of Operation" (the processor manual), then your operating system should, and generally does, run correctly on the bare iron.
As for whether you'd want to do that, in some cases, you can actually obtain a performance improvement by using VM instead of running on the bare iron. For instance, if you are overcommitting memory, you will generally get better performance by giving a flat address space to your virtual machine and letting VM do demand paging then you would by letting the host operating system do its own paging.
Plus, the 40000+ Linuxes in a box was a stunt -- done to show that it could be done. No one in their right mind would *want* to do this in a production environment. Four or five Linux images would be more realistic.
A production VM, a testing VM, and a developmental
VM for each of your developers. Your developers can do whatever they want to their own image of Linux. Play with the kernel, crash it five times a day, reload it from a backup in minutes. As your developers develop stable code, they implement it on the testing VM, and the "beta testing" takes place there. Once they are confident, they put their work on the production Linux.
Note that since VM can easily share disk space, you don't have to necessarily FTP anything around. You could just dismount a filesystem from one VM with one command, detach the virtual disk drive from that machine and attach it to another virtual machine, and mount the file system on the other system, all in a few seconds.
You gain a lot by running VM, and many sites do so because the advantages gained easily overwhelm the slight performance hit, if any.
- John
You don't need to use LPAR. In fact, we ran VM native on our 3090 with no LPAR, and ran MVS as a guest. We could have run VM and MVS in their own partitions, but LPAR requires you to dedicate resources, and running MVS under VM allowed all of the resources to be used by either operating system on a demand basis.
Actually, in your example of dedicating an entire box to Linux, there would be no reason to use LPAR. You could switch off LPAR and get a slight performance improvement.
Rumors are that LPAR was an internal strategy within IBM to try and eliminate the need for VM on customer machines, at a time when there was considerable infighting between the MVS group and VM groups. As in the MVS people wanted VM eliminated. LPAR mode is nowhere near as flexible as VM and isn't a substitute. About the most that can be said for LPAR is that it gives you an extremely limited subset of VM's capabilities without your having to have VM.
Something that hasn't been mentioned here is that VM has an interesting configuration option called "V=R", which stands for "virtual (storage) = real (storage) that allows you to run a single virtual machine in real memory starting at address zero, eliminating VM's page tables for that virtual machine!
This can be a huge win if that single virtual machine happens to maintain its own page tables (like VM, MVS, or Linux.) Normally, VM itself has to maintain what are called "shadow tables" -- a set of real page tables that map the virtual page tables in your virtual machine to the real hardware memory pages. Every time your virtual machine changes its page tables, it issues a "purge translate lookaside buffer" instruction. This privileged instruction is intercepted by the CP nucleus, which has to then re-examine your virtual page tables and recreate the shadow tables for the real hardware.
Say you want to give your MVS virtual machine 256 megs of memory. There is a way to tell VM to load its kernel above the 256 meg line, and not use the memory below 256M. Now, when you start your specially-identified MVS guest, because that virtual machine is assigned contiguous memory starting at location zero, VM no longer has to maintain shadow tables for that virtual machine; it can allow the V=R guest to directly manipulate the page table registers when it runs (subject to hardware bounds-checking, of course, to make sure the guest stays in its assigned memory), and that virtual machine can run that much faster.
This is something that isn't even an issue with Linux, because Linux doesn't allow your processes to maintain page tables. There's no notion of virtualizing the paging hardware, and no need for something like a V=R guest.
I don't know if V=R mode works with Linux. I'd be interested to find out, and to compare V=R Linux virtual machine performance with native "bare iron" performance. I bet there isn't much difference.
Another thing to consider is that the S/360, S370, and S/390 processors and operating systems have maintained object code compatability for over 30 years. This drastically simplifies processor upgrades, which is something to consider.
So?
What is your point?
Who said that these cannot be ported. And they are not a problem to be ported even if remaining closed source due to licencing.
The problem with Linux 390 is elsewhere. If you
have not noted linux:
1. Does not yet support SNA well, which means it will not integrate with lots of old apps for now.
2. The current port has no network adapter sharing across VMs which means that a network adapter is blown for every VM which is bad.
So it has some way to go yet - someone has to clean up an SNA stack and someone has to get the virtual network support properly done. And these can prove to be problematic contrarily to porting JCL control programs.
Baker's Law: Misery no longer loves company. Nowadays it insists on it
http://www.sigsegv.cx/
In my experience raises are tied to successes more than they are tied to office politics. The guys at the top only understand one thing: money. It's up to the IT department to translate everything it does into that lingua franca correctly and to argue effectively for its initiatives in terms of the organization's bottom line. What usually happens is technical people go with what they know, rather than doing their homework to fairly analyze all options, no matter how unfamiliar. Thus biased, they attempt to justify major capital expenditure to migrate to their favorite platforms and languages. Sometimes they succeed and sometimes they fail. Their raises are tied to how well they did what they said they would do, not if they choose the best approach.
Therefore, I cannot tell you whether or not you will get a raise, but I could make a guess...
Regarding obsolete hardware in the glass house, you seem to be describing an organization has not upgraded a platform and is having problems "right-sizing" it out of existance. Some of those applications must be starved for migration resources for this to be true, n'est pas? It's a pity you can't finish the job and start saving all that money the mainframe's costing you.
BTW, how big was your last raise? Or was this all hypothetical? If so, what was the point you were trying to make?
>>Unix has KILLED the mainframe market.
That's why IBM has has had a record number of sales.
>>... old-technology dinosaurs
Actually mainframes are a good development ground for new technology. Large businesses can afford to pay for expensive stuff. Things like copper processors and fiber channels are not uncommon on mainframes. The last time I checked my PC wasn't even using dedicated I/O channels. When the technology becomes less expensive then it generally goes to lower end processors. Simple economics.
>>VMWare can do exactly the same thing. As could SoftPC from Insignia.
Except I believe that VMWare & SoftPC need to accomplish a lot of this through software emulation due to processor limitations. Most of VM is done at the hardware level to avoid the emulation slowdown. And, of course, VM has been doing this for decades.
>>...old-fashoned Grateful-dead listening gray haired bearded mainframe COBOL gurus...
Actually I'm a 28 year old OS/390 Systems Programmer who doesn't like the Grateful-dead and really dislikes COBOL. I've never even had a beard. I will admit I have a few grey hairs (darned kid).
>>...themselves seem "sexy"...
My wife thinks I'm sexy. So there.
>>...hot new IPOs they think of Linux, NOT IBM.
I would hope the public they don't think of IBM. After all, the I stands for INITIAL and IBM has been a backbone in the stock market for decades. I am curious, when is Linux going to have an IPO? I must be too ignorant because I wasn't even aware that Linux was a company.
>>...shave off those beards, come out from behind the glass wall and start interacting like normal human beings.
As I said, I don't have a beard and my data center doesn't have a glass wall. I guess I deprived. When I want to interact like a normal human being I'll be sure to do it as an Anonymous Coward on a web site.
>>...pretending they are "Scottie" on the Starship Enterprise, and acting like nobody understands computers except them.
I don't pretend I'm scotty. I've always been partial to Mr. Spock. I don't pretend that nobody else understands computers. I just pretend that nobody understands MY computers like me (and most people don't). A subtile difference, but a difference never the less.
>>...centralising...
Unless you work in a small peer-to-peer network, every server is a "central" place. That's the whole definition of "server".
>>..."technical experts"...
I prefer the term "technical specialist" because few people are true experts. Most are like doctors in that they are good in a specific area. Running a linux server doesn't make you a technical expert, just a specialist.
>>...but no, they refuse to go away
As soon as all the work goes away, I can assure you that we won't be around. So far I've seen nothing but large growth in my regions.
>>...refused to create me an account...
If it's obsolete, why do you need an account? Just run the work from your Sun box.
>>What century is this ?
The same century as it's been for the last 99 years. The 20th century. The 21st doesn't start for about 9 months.
>>Forms ?
Those are those pieces of paper you actually write on and place them in the mail because workflow management hasn't been implemented in a reliable fashion at your place of work. This isn't a mainframe issue, but a process issue.
>>Please spare me!!!
Sounds like since you didn't fill out the correct forms, you spared yourself.
>>...Solaris as the OS of choice for high-volume OLAP and OLTP applications...
Most of the worlds data still resides on mainframes. The vast majority of business critical transactions still run inside CICS. When large amounts of money or resources are on the line most large companies still reside on the mainframe because it's too reliable to replace.
>>...the death knell for these anachronistic monsters...
The mainframe has been declared dead more times than the Amiga (and that's a lot). Most of this took place in the 80s & early 90s when midrange & PCs were going to kill it. We're still here. Now with the Internet mainframes are growing again because on the backend nobody cares what the OS is as long as you can get to it through a browser.
>>thank you
No, thank you for posting such a biased, well thought out, resarched post.
The author is missing the point. The geek who ran 40k+ copies of Linux at one time was doing it just to be a geek. Period. I seriously doubt there is a person out there who would need to run that many copies of Linux on one box.
IBM builds some pretty sweet hardware when it comes to mainframes. The darn things are build from the ground up to handle mutiple users and OSs smoothly and efficiently. The IBM 3090 we had at college was pretty darn responsive even when both processors were at 90% utilization.
It's not an issue of trying to run 40k+ copies of Linux, it's about having a stable, fast, and large platform to run an OS.
--
then it comes to be that the soothing light at the end of your tunnel is just a freight train coming your way
Exactly my point. Business users do not care about your "hot-swap" technology
What are you smoking?
Businesses do too care about this. Maybe they don't need 100% uptime, but many businesses have times when they need a near 0% chance of the system going down.
I've personally sold hardware raids with hot swap to the tune of 20K$ to small businesses that have to provide their customers with reliable, on time service.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
OS/390 is Unix branded, and gives a reasonably good Unix enviroment, which is well integrated with the other S/390 OS's. For example, I can access a dataset created in ISPF, or setup a job to be restarted with appropriate JCL automatically by zeke, just like any other mainframe job.
I used to use an old 3081 that was rated at about 1 mip. It was much slower than the most pathetic sparcstation I could find with calculations...you could almost hear the bits flip over. It did how ever have a very impressive up time (409968000 seconds at least if not twice that) and it also could move lots of data between devices very quickly. As far as I know the box never had a second of uptime since it was installed.
Of course the management loved ranking machines by MIPS or MIPS/sq ft. The new (at the time) sun 690 (218 mips?) was the best box in the place. It of course did nothing but eat juice till I put usenet on it.
Obviously you wouldn't try and run 40000 copies of seti@home or some such, you wouldn't get enough CPU time each.
You could however use the machine as a file server or a web server without paying any hardware or software costs. This could make a big difference to a company who has a mainframe sitting in the basement. The next time someone wants to get a windoze server for their workgroup, you install samba or apache on the mainframe and skip the $10000+ for hardware and licenses.
Or you just install it temporarily while the permanent boxes are being ordered (which can take 6-12 months for a large enterprise, not kidding).
You don't even need to install Linux, samba and apache already run on OS/390.
This is the real value proposition for large businesses, avoid M$ tax, server room wasted space and yet another box to maintain.
Mainframe prices have dropped a LOT in the last few years. Amdhal has posted prices for some of the low end models at: "http://eshopamdahl.com:80/eshop/millennium/config s.asp". You can pick up a 1 CPU 94 MIPS machine for $240,000. Keep in mind that Mainframe MIPS are not directly comparable to other architectures. The largest model posted is a 5 CPU rated at 371 MIPS. Amdahl is shipping a 16 CPU model rated over 2000 MIPS.
Don't be an idiot. This article applies to us because a large number of the /. audience is interested in learning more than what is 'applicable' to us.
I know I love reading the myriad of articles that get posted here, generally I learn something new and that is a good thing.
forge
From what I understand, the Linux port doesn't run "Natively" on the raw iron. It would have taken much longer to write if they'd written it that way -- VM hides a few features of the iron from the OS, the ability to do VM's quite simply being one of them. There's been some discussion of hacking the OS around to make it run as the main S/390 OS but most agree that it wouldn't be worth the effort since almost no one would actually do that.
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
I have to ask, what's wrong with running 40K+ separate servers? I understand that Linux itself is multiuser, but why not both multiuser and multiserver? I had run across this site, www.rhyton.com recently and saw that they claim to offer this ability - that you can have your very own virtual server to do as you please - not an account, but a while (though virtual) server. If this is the same kind of stuff, I think the IBM has great potential of being a great ISP's dream come true. Am I wrong here? Do I have my facts wrong? Someone please tell me.
Linux: It's everywhere you want to be.
kwsNI
No, Linux runs native on "raw S/390 iron" ... it also runs in a S/390 Logical Parition (LPAR) and also under VM. Three operational options ... same exact Linux code. Check out http://www10.software.ibm.com/developerworks/opens ource/linux390/ for more details.
For instance, many small business have web sites with a very small amount of traffic. Currently these are often hosted on shared servers with other sites - often very many other sites, since the loading for each site is very low. Out of 40,000 sites you would likely find that less than two hundred are actively being visited at any given time, and even then the server will be mainly IO bound rather than CPU bound.
So the suggestion that a virtual machine on a mainframe could be used for each site rather than just a HTTP1.1 virtual server is actually quite interesting, and certainly viable. It would solve some real-world problems too - security issues in particular.
This is just one example - there are plenty of things you could do with 40,000 virtual machines on one box. The author of this piece either hasn't thought it through or is guilty of the same "parlor trick" that he accuses Scott Courtney of.
And yes, you could do 40,000 on one mainframe - indeed, you can do 40,000 on one Linux box if you have the right setup. I've worked with a server farm running a half-million user homepages off six Compaqs.
So you're calling us clueless because we're talking about mainframes? I mean that's great that you are involved with IBM and get to play with their newest stuff.
Now quit, and join a company who spent the big bucks on getting the big iron, decades ago, because they wanted something big, big, big. Now, convince them to toss those big expensive, contract maintained boxen out next to the dumpster.
Go ahead. Try it.
Now, convince them that you can repurpose that decaying beast that does less & less every year, into a modern powerhouse driven by the Latest and Greatest Buzzword Compliant [tm] Open Source [tm] software.
You try that. Then, tell me which of the above two solutions gets you a raise as an IT/IS professional.
I've noticed most of these S/390 discussions go round and round again on the same things. To me this indicates different people are speaking up each time and haven't read prior threads. I recommend you folks read those articles and discussions. Here's a link to a reply I made to an earlier discussion to help you get started.
You don't need S/390 hardware to try this stuff out. There's a wonderful S/390 emulator for I86 Linux called Hercules that you can run S/390 Linux under. So rather than throw bricks at what you don't understand, try getting your feet wet. Linux on big iron is going to be significant. Start getting ready now.
I'm sorry, but I'm going to have to disagree with the comment that running 40k copies of Linux on a mainframe is not useful. Think of ISP's or other companies that do co-location of servers. How about telco's that do it? The cooling systems, battery backup, backup generators, human maintainers, etc...cost a fortune to operate in a large data center. What if one was able to take an ACRE, yes, an ACRE of servers and replace them with one s/390? The cost of floor space over the course of a year would pay for the mainframe.
You may not need less people to maintain it, but you will certainly need less facilities. I data center I've worked in charges over $20 per square foot per month to host a server. Multiply that by a couple of thousand and that mainframe starts looking VERY attractive...
kwsNI
Part of the vaunted S390 uptime comes not only from the overt reliability of the the hardware but also from the reliability of MVS itself. You don't necessarily get the same reliability from replacing MVS with Linux. Moreover if you consider not only uptime but MTTR you will find that in the S390 arena those figures come at the expense of years and years of practiced discipline, at knowing just how to find and fix things quickly and exploiting a well understood break/fix methodology to remediate the problem. This is not necessarily the case with S390 Linux now and would require some years of experience to get there.
It seems that S390 Linux best serves service providers who can bill out chunks of a box to whomever wants a particular service hosted there. If this is the case I'm left wondering why it makes any difference what OS runs under the covers of a hosted service? There are two cases that we have to consider.
One - somehow the service provider can offer a cheaper service because there are zero or near zero OS licencing costs. If look at maintenance, labor, hardware leasing, etc. Is the OS licence a significant enough to lower the overall cost model of a hosted service. True MVS can be expensive but we've already assumed that the expense would be allocated to many customers.
Two - are there applications that are not supported on MVS or AIX but are supported on Linux in this space where a service provider would host a commercial service for a customer? Gee - I can't think of one in the realm of the SAP's, UDB's, Oracle's, Lawson's, Webserver's, etc... Or alternatively are there applications that can be procured from the vendor for significantly less if they are licenced for Linux and not anything else? Perhaps but not likely.
In the end I can't how this makes a great deal of business sense however interesting it is to do technically. Having said that there is one exception - the case of development + migration. I can a see a case being made for developing code in some other Linux platform or in an instance on an LPAR and then more or less easily being able to test and migrate it to production on a similar Linux platform in the LPARs. Today for example when we have to develop something in UDB/DB2 on say NT or Linux on a PC and then have to move that code upstream to an S390 there is a whole basket of problems that you can't avoid. It is possible that S390 Linux would reduce or even eliminate those assuming the DB or applications vendors themselves write more or less unified code for any Linux platform and the developer doesn't have to think about things like IO performance, locking, security and whatnot.
So, when I read about the S/390 version of Linux I started half serious (but half joking, too) to analyse replacing 24 low- to mid-range boxes with one S/390.
Aside from the cost of scrapping the 24 not-so-cheap machines and paying for a very expensive S/390, the maintenance costs are higher for a properly configured, working, redundant S/390 system. Much much higher. At least for now, it's just not a cost-effective proposition.
Some people, invcluding the author of this article have NO clue about true costs involved in a S/390 system. The system itself can cost as much as a mid to high end Sparc box. The processor is at least as powerful, but that's not why you'd want to use it as a web server. Mainframe has KICK BUTT I/O. Mainframe are MUCH more efficient at pumping I/O. You could use a mainframe to stream audio or video on your web site with copy, and a another copy could do the web serving. Also, the main cost of operating a mainframe is NOT just the hardware support, it's the software. We pay one vendor 20,000 a year just to get support and software updates! With Linux under VM, only thing you have to pay for is VM. You can load as many copies of Linux as u want on the mainframe. Also, you could probably use existing bus and tag and ESCON devices such as printers, tape silos and DASD as native devices under Linux. There are mainframe printers that can print 90 plus pages per minute! Granted, some of the mainframe reliability can be attested to software, but on our current system, we have 2 power feeds (you split those between two power substations), we have had RAID for YEARS longer then PC server's have had and we have been serving 2-3 million data requests a day and this was on a 10 year old mainframe, running DOS/VSE, a cousin of the first mainframe OS that MVS was to replace, but is still going strong. Our new one hasn't even scratched the surface of the power we have available. Oh and lest I forget, they can call themselves for service before they die. We have had disk packs go bad and we NEVER went down or knew we had a pack go out. Also, ESCON, a fiber based way to connect channel devices to the mainframe, can have a range of 4-5 MILES before needing a repeater (if one wants to lay that much fiber! Be cheaper to use the OSA ATM or Fast Ethernet adapter and do it with TCP/IP).Um, lessee, scheduled downtime is limited to changing time (we have to do it this way to preserve data integrity), some software updates do need a IPL too, OH and in my opinion, the MF can boot faster too! Gork
Gorkman
What that original article was really going gaga over was VM. I can understand that - VM is really sweet - but I doubt the configuration would be that useful.
However, I think Linux could be useful to mainframe sites like us. Here's why:
Very straightforward - except that the overhead of running OS/390 just to support Unix System Services is high.
Therefore I'd say that a probable - no, make that possible - future configuration for us is a partitioned S390 box with one slice running OS/390 and hosting the database and the other running Linux/390 and doing the web serving. Much lower overhead, I'd guess.
BUT there is no way places like ours will make a commitment to Linux/390 without substantial IBM support.