Slashdot Mirror
Mainframe OpenSolaris Now Available
BBCWatcher writes "When Sun released Solaris to the open source community in the form of OpenSolaris, would anyone have guessed that it would soon wind up running on IBM System z mainframes? Amazingly, that milestone has now been achieved. Sine Nomine Associates is making its first release of OpenSolaris for System z available for free and public download. Source code is also available.
OpenSolaris for System z requires a System z9 or z10 mainframe and z/VM, the hypervisor that's nearly universal to mainframe Linux installations. (The free, limited term z/VM Evaluation Edition is available for z10 machines.) Like Linux, OpenSolaris will run on reduced price IFL processors."
I have a big old z in my basement that I've been itching to upgrade!
This is my sig.
And IBM mainframe running Solaris...
Now I have seen everything. Next AIX on the Sparc.
See my blog http://ilovecookes.blogspot.com/ for light hearted technical information.
The way I see it, IBM is in the business of providing so much choice to customers that they need expensive IBM consultants to help them decide.
;).
Microsoft will sell you the Microsoft Way of doing things.
Whereas IBM will say "You want a Active Directory server, a Z mainframe with RedHat, OpenSolaris and Oracle, Cisco switches, and there must be full J2EE buzzword compliance? No problem, just sign here".
Careful to make sure they will actually do the job though, and not outsource it to a bunch of fresh PHP coders in India
IBM has a strangle-hold on the high-margin mainframe world. This is causing issues in the Big Blue God Pod right now, be certain.
Website Hosting
Everyone knows a mainframe is supposed to have blinky lights
Is an array of 1,680 by 1,050 blinky lights enough for you?
and tape spindles whirrying about.
You mean like LTO backup?
Someone is already working on bringing Microsoft Windows to the mainframe. Who could have imagined.
Seriously, I've run Suse 10 on an IFL engine. It's so slow, I don't know how anyone could run anything serious on it. I have an old laptop that matches or exceeds the performance in about every measurable way. Mainframe Linux and now Mainframe Solaris is a joke.
That post reads like those Dr. Bronner's Magic Soap bottles.
Never underestimate the stupidity inherent in all human beings.
Solaris only works on Apple Mac Supercomputeres.
No, that'll only be true after Apple buys Sun, which by my calculations would require approximately 15 minutes of iPod sales revenue.
I have some Z80 boxes in my basement...
Ive never seen a System Z, and then only Sun boxes I've ever seen in real life are the ones I've owned. But from my experience with Solaris, and Sparc, Its the best damn arch/OS ever made. Im a big Linux fan (my /. nickname is a joke ;) ) But if it were up to me, id run everything Sun
Way to go boys! now, There real Question is:
Solaris and System z: How well does it run crysis ;)
Go go Gadget Nailgun!
I'd still like to see Solaris and/or BSD come to the IBM Power Systems line. I think it'd be pretty cool to run Solaris or *BSD in an LPAR next to i5/OS and/or AIX.
The killer app will be the Big Blue Screen of Death.
Seriously, I've run Suse 10 on an IFL engine. It's so slow, I don't know how anyone could run anything serious on it.
That's why their called 'z's zzzzz zzzzz zzzzz....
No, seriously, mainframes aren't about performance. They're about stability. Think about 16-core server with 40 GB of RAM running Solaris, AIX or Linux as a Ferrari Testerosa, while the Z10 is more like Abrams M1A1. Not as fast the Testerosa, but pretty quick for something that weights over 60 metric tons....
My blog
Your laptop can meet or exceed the IO performance? How about the memory access performance? Your laptop has MTBF measured in decades? Or by 'every measurable way' do you mean simple CP performance? These machines are not about CP performance.
Stability. That's what everyone always comes back with, but it seems like the Mainframe side of my company has as many unplanned outages as the distributed side. Not to mention we run circles around them in terms of data processing.
I bought three cases of that, you insensitive clod!
Web2.0: I love when people Flickr my cuil and digg my boingboing until my google is reddit and I start to yahoo
Yes, even the IO performance which was surprising to me. It's running on an older Mainframe, i.e. not a new Z10, but still. Granted, I'm totally at the mercy of the Mainframe admins that control DASD access. It doesn't matter though, even if I had faster IO, you still have to have the CPU to process the data once it's been retrieved. My tests showed that the CPU spent less time in IO wait, but they were so slow to do anything else, it didn't matter.
Stability and I/O (particularly disc) bandwidth. Very important.
No folly is more costly than the folly of intolerant idealism. - Winston Churchill
Got any data to back this up? Usually I find people who say such things have a distorted view of reality. Not saying that you do, but I hear people say that and almost none of them have real evidence with which to backup their statement.
My blog
Solaris only works on Apple Mac Supercomputeres. Plus it is not for Christians who believe in God and also Jesus Christ. Because if you use Microsotf you are not a Jew or a Mohammadean infedil. Please everyone remember to cast your votes for McKaner or OBOMA. They are Christians who love Jesus and Unixes of the Holy GHOST.
Andy Warhol got it right / Everybody gets the limelight
Andy Warhol got it wrong / Fifteen minutes is too long.
With all due respect, your mainframe people must be idiots. Nothing comes close to big iron in terms of processing capabilities and uptime.
Web2.0: I love when people Flickr my cuil and digg my boingboing until my google is reddit and I start to yahoo
Right. I forgot the part about I/O bandwidth. It's more about the utilization rates than about the speed of any one task/transaction/etc.
My blog
That's a distinct possibility. It's something I have believed for quite a while...
If a mainframe doesn't have damned near 100% uptime then someone needs to be fired. Those things just don't break. Hell, they phone the service engineer for you *before* they break and you suddenly get the IBM guy turn up on the doorstep with a replacement CPU (which is hotswapped.. no downtime).
No, they purchased an IFL. Not with the intention of me playing with it, but with the intention of running DB2. Sales people convinced them this was a good idea. From our testing, it's completely unacceptable.
It's not the hardware fails, it's the third party software that fails.
From what I've seen in a SAN in a mixed environment, it certainly isn't the mainframe that's exposing the FC bottlenecks. It's a long time ago that the mainframe had any special hardware.
Frankly, I've heard so many sales pitches for so long that there's only one thing that matters. Publish the benchmarks or it's just hot air.
In the case of mainframes I haven't seen any serious benchmarks for more than a decade. I expect performance to be entirely predictable from that point only.
If this is true then your mainframe guys need to be fired ASAP.
It used to be a standing joke that nobody got fired for buying IBM but they did if it EVER went down unplanned.
Also the throughput on a mainframe is truly astounding. I hate to think just how bad the software must be for a mainframe to be considered slow!
Heh. Think about this: At a former client of mine (your typical $LARGE_CORP) they had three physical boxes, I forget how many sysplexes and a number of LPAR instances. Two LPARs (one each ona separate physical box) where responsible for production (one hot, one spare). Between them they had something like seven years of actual service uptime.
I'll never cease to be amazed at that culture and how different it is from ours. Changing a network card (or whatever) on those things required a gaggle of IBM consultants ($230/hr baby), three months of planning and a budget that would put most of my projects to shame.
Still, you have to sit there in awe when one of those old farts tells you about how they can swap out processors without shutting down the machine.
Web2.0: I love when people Flickr my cuil and digg my boingboing until my google is reddit and I start to yahoo
Exactly.
From what I've seen, weekly IPLs seems to be close to standard practice within the mainframe world. With a reboot frequency like that you're not going to even see most stability issues.
Has it even become possible to switch to and from daylight savings yet without rebooting the mainframe?
almost none of them have real evidence with which to backup their statement.
Yes, well, rather like mainframe benchmarks, eh?
That having been said, the next logical step would be to compare the amount of compensation that mainframe operators are getting versus that of other server operators.
"If a nation expects to be ignorant and free in a state of civilization, it expects what never was and never will be."
Or maybe Java with plain text paragraphs?
I hate being bipolar; it's awesome!
When the PowerPC CPU was first introduced, everyone was going to play on the new platform. IBM AIX was trivial, of course, because the PowerPC is based on the POWER CPU. But there was Windows NT 3.51, Mac OS of course, and this thing from Sun called Solaris.
Sun decided to stay with their own chips and then branched out to Intel x86 and AMD64, Microsoft eventually went back to an all-Intel code base (dropping Alpha support as well). The real killer for those boxes? IBM's port of OS/2 failed. Failed hard. ('Cause they did a top-down port: GUI first.) The PowerPC survived only in Macs, RS/6000s, and a bazillion embedded devices.
This time, though, I think the Series z machines will stick around, even without an OS/2 port. Gotta give Sun credit for trying the IBM thing again.
Customer: Hello, IBM, I want to run *ix on my mainframe.
IBM: Sure. Are you wanting Novell SUSE Enterprise Linux Server or Red Hat Enterprise Linux?
Customer: Sorry, I meant Unix...
IBM: Sure. So you are wanting Unix System Services?
Customer: No I want to run that new openSolaris on it.
IBM: Let me get this straight, you are wanting to run an unsupported hobbiest Unix variant on your multi-million dollar mainframe, correct?
Customer: Uhh... no, I want openSolaris... oh... wait a minute, I see your point. ... pause ....
Customer: What were those Linux choices again? ....
SPARC and X86 are recompiles from each other already, never mind 32-bit v. 64-bit. z/Architecture is now another choice. Which is why OpenSolaris for System z will be of primary interest to companies that have their own in-house applications available to recompile. (Vendor applications are another question, at least initially.)
Yes, you could move from Solaris to Linux, and many people do. Some people don't want to. This is another choice. You can run multiple operating systems (including Linux) concurrently on a mainframe of course, and almost 100% of mainframe owners do. So you can mix and match. Run DB2 on z/OS and your in-house C/C++ application on OpenSolaris on the same machine, as one example.
Mainframes are typically for number crunching apps. I had to run some comparisons and for the RHEL5/WebSphere Process Server (ESB) combination we ran - it was keeping up quite well with transactions. I had to pull them back when the business was suggesting to run their web server there. The cost was not justified.
"You killed my yogurt!" --Fred Fredburger
this tells you all you need to know about the whole project
no. gotta have a z9 or z10. it wont work on a z800 or z900 either.
Every time a mainframe story comes up on Slashdot we seem to get the skeptics who point out that an X86 processor core can add or multiply two numbers (stored in registers anyway) about as fast as a single System z10 core, at least as long as they're integers. (z10s have hardware decimal floating point.) Based on this brilliant SPECint-y observation, combined with the fact that a System z10 EC Linux processor has an advertised one-time charge of $125K, these "experts" thus conclude that no one could possibly buy a mainframe because it's just so darn expensive. (Note that's one-time charge, folks: if you do a hardware model upgrade typical IBM practice is to charge you something for the frame swap but not to charge you again for turning on the processors.) Of course, in the same discussion people don't bother to explain why the same argument also holds for SPARC CPUs. Heck, why not run business applications on Sony Playstation 3s or ARMs? They're even "cheaper."
May I humbly point out that IBM just posted (yesterday) another record quarter for mainframe sales. Revenues were up 25 percent, with double digit growth in every region of the world. Because prices are higher? No, the opposite: shipped capacity was up 49 percent; specialty capacity (including Linux processors) was up 120 percent. And IBM has been posting quarters like this for years now. This mainframe stuff is wildly successful and gaining marketshare.
Why? Because, with all due respect, you're an idiot if you stop your careful business case analysis at the first sentence above. Unless you're running SETI@Home, rendering the next Pixar movie, or simulating nuclear explosions, business applications across many users just don't run that way. Companies (particularly CFOs) and big data center managers are not (generally) idiots. They buy this stuff because it works wonderfully and because it's cost-effective, taking all costs into consideration. Think $125K (once) is a lot of money? What's your salary, dude? Who are the richest single human beings in the software industry, and did they get that way because software is free? And how much did it cost the London Stock Exchange when they couldn't trade? Are you the guy who wants to explain why you have to build another $20M data center because you can't power or cool yet another X86 chip? In the real world, there are single companies running hundreds of these mainframe CPUs. And they run at 80%+ busy 24 hours a day, by the way.
Honestly, there are way too many Slashdotters who are much more the stubborn non-thinkers that they probably accused mainframe-skilled people of being a few years ago. It's a different world: grow up. The boring but wonderful truth is that -- surprise! -- different servers are good at different things! Intel/AMD X86 servers are useful in certain ways, and so are System z servers. Even in the same data center. Wow, what a concept!
I doubt there's a reason for the IPLs (reboots). If your mainframe operators are doing it, they're probably just doing it because (seriously) somebody had a memory leak 30 years ago and that was how they "fixed" it. And nobody bothered to update the procedures manual. Nor did anybody ask them, "Hey, can we improve the SLA (Service Level Agreement) here?" "Sure boss, I'll just stop IPLing. Let's try skipping the next one." That's usually how that conversation goes, seriously.
In fact, if you've got a Coupling Facility and two or more LPARs (partitions), even on a single machine, then you can reboot either of them as often as you want and no users will care. Transactions keep humming in CICSplex and IMSplex, databases keep running with DB2 data sharing, etc. If your operators haven't implemented that, that's their choice (or negligence?), not the technology's.
Hey, good eyes.
You'll notice that the release notes also refer to "phase 4" in a number of places.
The current awstape image is "phase 6"; we're revising the documentation. That paragraph no longer exists. Do what you like with the loader, including preparing your own ramdisk. The source is available from Sun; just follow the links on the page.
Phase 4 was a non-public release, which did not, in fact, come with source code. Phase 6 is the first public release. Knock yourselves out.
Adam
Relax, people. Keep in mind that this was NOT an IBM or Sun project -- they were dealing with an outside entity who was doing the work, and was working with copyrighted intellectual property not owned by IBM. During development, we were working with some internal IBM people doing testing. For reasons that should be obvious to anyone who's been conscious and following the IT news during the last few years, IBM did not want to see ANY source code for ANYTHING lest they be accused of stealing it. That paragraph was left in the release notes by accident. The entire source is posted on opensolaris.org according to the requirements of the CDDL and the rules of the game. It *is* fully and completely open source. David Boyes Sine Nomine Associates
Ahh. Well then that is your problem. That shouldn't happen at all. Also when you talk about through put you should look at strengths of the two systems.
If you are doing anything with a lot of floating point. The Zmachine will lose to Intel every time. If you want to do that then get one of the Big Power boxes, a bunch of X86, or one of the big Itantium boxes with a lot of cores.
If you are doing millions of database transactions and you want to make sure that it NEVER goes down. Get a Zmachine with an application that wasn't written by an idiot.
See my blog http://ilovecookes.blogspot.com/ for light hearted technical information.
This is the problem I have had with Sun, and Sun consultants trying to talk to me, for the past ten years. You have refuted nothing of what was written. The answer is yes, you will need to recompile, and support for the compiler tools and runtime environment, as well as the applications, will need to be good enough otherwise this doesn't mean all that much. Applications are everything, which is where OpenSolaris is playing major catch-up.
People are not going to run Solaris on a zSeries for Dtrace or even ZFS, no matter how much people start jumping up and down and now matter how much Sun people look at you in disbelief that you might have other priorities. Your comment smacksof everything that is wrong with Sun for the best decade - the disbelief that you could run anything on a tin-pot consumer level OS and kernel like Linux, disbelief that anyone would not run a real Unix like Solaris or real hardware like SPARC and the mythical notion that although Linux might have claimed this area Solaris runs better on some undefined beefed up hardware.
I would laugh if it wasn't so sad. The truth is, Sun has everything it needs to make as much money as it wants if it would only ditch this cultural nonsense about Solaris and SPARC that pervades it.
The new documentation is up, although the documentation inside misc.vmarc and phase6.awstape is still the old stuff. I'll replace that over the weekend sometime.
Adam
So does the reliability of z come from the hardware or the culture?
This is a very good question actually. Although the hardware is in itself a good part of the equation - since it is built with availability in mind from the bottom up - the culture (and they way it is "forced" on developers) is a good part of it to. In the mainframe world development of applications makes uses of proven subsystems and transactional packages and the development is made in a way that greatly minimises outages: in a way the constraints that people dislike make it such a rock-solid platform).
Of course, nowadays one can develop in Java and most other "open" technologies, but the z/VM - /OS - DB2 - CICS - COBOL is still dominant I think, at least in cultural terms.
Applications are everything, which is where OpenSolaris is playing major catch-up.
People are not going to run Solaris on a zSeries for Dtrace or even ZFS, no matter how much people start jumping up and down and now matter how much Sun people look at you in disbelief that you might have other priorities.
Well, when discussing operating systems, the Operating System is everything. Otherwise, what is your argument, "The OS doesn't matter, but pick Linux/Solaris"?
Also, I'm confused, judging by the OpenSolaris reference, are you calling GNU software "applications"? Anyway, GNU software runs on ANY Solaris, and has generally done so for a longer time than it has run on Linux. GNU is not Linux centric and neither is much of the rest of the free software world.
disbelief that anyone would not run a real Unix like Solaris or real hardware like SPARC and the mythical notion that although Linux might have claimed this area Solaris runs better on some undefined beefed up hardware.
* Linux runs on everything from consumer level hardware like x86 (the same hardware that has ate SPARC's breakfast for about eight years incidentally) right up to the very same mainframe hardware that Solaris has only now been ported to.
Why focus so much on OS features being irrelevant in the first half, only to get ultra-defensive about it in the second half? That says a lot.
Linux runs on everything... What's your point? This is not a how-many-platforms-can-you-run-on contest.
Is z-series hardware more powerful than SPARC? I think that is pretty damned clear. Do we need to have our panties in a bunch because Solaris can run on it too? Man the perimeter defenses! The OS doesn't matter, applications do! Linux is the best anyway! x86 is good enough! But z-series is cool too, SPARC is a lie! Nya nya nya, I cant hear you, nya nya nya...
undefined == SPARC, was that really hard? Big SPARC systems are easy to find at www.sun.com. No really, Sun doesn't hide them or anything, you just never looked.
* Better under high loads and better throughput? Unsubstantiated and backed up with nothing,
Look, the hardware specs are wide open and fairly easy to comprehend. If you can't understand how something like a v890 can support higher loads and more throughput than any given x86 box, this discussion ends here.
I would laugh if it wasn't so sad. The truth is, Sun has everything it needs to make as much money as it wants if it would only ditch this cultural nonsense about Solaris and SPARC that pervades it.
Right, and by "ditching the cultural nonsense", you mean just pretend SPARC and Solaris don't exist? Declare Solaris and Linux, SPARC and x86 equals? Why are you so defensive about this? What can you tell me about SPARC hardware and the Solaris OS?
Did everyone ditch their intellectual honesty at the door when they "switched" from Windows to Linux?
What are you waiting for? Sun sells x86 servers WITH Linux! Solaris is NOT the same as Linux! SPARC is NOT the same as x86! Do you just figure you'll check it out if/when one of your peers does the dirty work first? Are you afraid you might actually find something better than x86/Linux? Do you need to feel challenged first or something? Uhh.. here, find me a Linux equivalent to "cfgadm -al -o show_FCP_disk"
Ahah! That was a trick, I'm making you learn something about something you're predisposed to disliking. I'm such a dirty trickster.
How about, prove to me how a Dell R900 has more usable IO bandwidth than a v490. Hah, another trick to make you research hardware differences.
I'll tell you what, a whole hell of a lot more people in the Linux community had better start looking closely at what else is out there, because a lot of you are just putting up defensive barriers and discouraging progress. When a company says nothing better exists, they're really working on 2.0. When a community says nothing better exists, it's collective ignorance.
Seriously though, software package support is a major failing of Solaris, and I say this having been both a linux and solaris admin for over ten years.
First of all, there are no fewer than THREE different F/OSS software stacks to use - coolstack, blastwave, and sunfreeware. Choice is fine, but redundancy is bad. I didn't understand why many admins define every executable in a shell script as a hard-coded variable until I realized that there was a /usr/bin/tar, /usr/ucb/tar, /usr/xpg4/tar, /opt/csw/bin/gtar, /opt/coolstack/bin/tar, /opt/sfw/bin/gtar, and so forth.
Second of all, none of the three of these have the amazing dependency handling of a modern linux package manager like apt. I can install a basic debian box, type apt-get install bugzilla, and have it pull down apache2, mod_perl, mysql, install and configure the bugzilla database, download and enable all the mysql modules for perl and apache, ALL IN ONE COMMAND. It takes several hours to do the same thing in Solaris.
I'm not saying that Solaris is useless, or that Linux is perfect, just that the original poster is dead on the money that Solaris application support (or whatever you want to call software packaging) is years behind.
Causation can cause correlation
IIRC, it was Solaris 2.5.1. Since porting Solaris at that time meant porting Sun's compilers, there was a version of Workshop ported for the PowerPC (which was mentioned in Version 4.2 of the compiler suite).
"Hey, can we improve the SLA (Service Level Agreement) here?"
Usually, the 'scheduled' IPL's don't count into the SLA uptime measurements, so it doesn't seem like there's much pressure to avoid them.
Sure they do, at least in most mainframe operational organizations. (Non-mainframe operations are a different story. You ask "what about avoiding planned outages?" and they look at you funny.) In fact, it's even possible the reboots aren't actually happening, but the operators have reserved the right (in the SLA) to do them, so they declare that early Sunday mornings (for example) are planned outages. If you want a different SLA, ask for it. This certainly isn't a technical problem.
From what I've seen, weekly IPLs seems to be close to standard practice within the mainframe world. With a reboot frequency like that you're not going to even see most stability issues.
We run IBM z Series mainframes on behalf of a large number of customers and the typical IPL frequency is now about every 2-3 months. It could probably be less frequent on some systems. If you *have* to IPL every week, you're not running your system properly.
Has it even become possible to switch to and from daylight savings yet without rebooting the mainframe?
The hardware and OS support it but as there's no way to guarantee the behavior of the (particularly non-IBM) software products and the applications (which are especially *not* expecting the clock to go backwards), so it's too risky.
I would wonder how well any software on a non-mainframe platform (e.g. Oracle on Linux) would cope with time going backwards - surely this would screw up the logs etc?
We *could* probably take down all the databases, CICS services, non-IBM products etc., change the time, and (after waiting 1 hour in the backwards case) bring them all back up *without* an IPL but by the time you've done this it's probably a lot safer just to follow the standard IPL sequence.
The other thing is that certain changes (e.g. base MVS fixes - equivalent of Linux kernel changes) do require an IPL as they would require a reboot on Linux. As we only IPL about 4-6 times per year we really need the clock change IPLs for putting other changes in.
I would wonder how well any software on a non-mainframe platform (e.g. Oracle on Linux) would cope with time going backwards - surely this would screw up the logs etc?
Time on Unix platforms basically doesn't go backwards. It's defined as seconds since 1970, and the number of seconds since then goes only one way.
How that information is _presented_ to human consumers is a different matter, and it's at that layer the DST stuff is done. So presentations for human consumption like time stamps in logs can be ambiguous, depending on how the application writing the log decides to format its timestamps, but software never gets confused; things happened when they happened, no matter what that may get called depending on time zone or politics or country.
(Of course, if you changed the actual clock you'd run into the same type of problems on Unix, which is why it's not done that way.)
Time on Unix platforms basically doesn't go backwards. It's defined as seconds since 1970, and the number of seconds since then goes only one way.
If you run your IBM mainframe in the recommended fashion, the system time is always set to CET/GMT and so never goes backwards. Applications may use the system time or the local time. However, if you use the local time, this *will* potentially jump back one hour, and if your application is not written to deal with the same time occurring twice, it will have problems.
Essentially the issues on mainframe or *NIX platforms must surely be the same? You can run the system clock itself on local time (with DST) or CET; the applications can request the absolute time or the local time. Some of these combinations will give incorrect results, particularly where there are very old applications which ask for the system time when they should be asking for the local time, because when they were written system time was always local time. So although the issues are the same on the different platforms, problems will probably occur more often on mainframes due to the relative code age.
It's an amalgam of both. You can still screw up a mainframe environment just fine, which is why I suggested to the OP that the people at his company might be idiots.
Web2.0: I love when people Flickr my cuil and digg my boingboing until my google is reddit and I start to yahoo
By no stretch of the imagination, is a linux binary future-proof. Linux probably has the least future-proof ABI of any reasonably popular OS.
More importantly... Linux, and all Unices, are all about source-code. Traditionally, you got the source and built the app yourself. Modern distros of Linux, BSD, Solaris, etc. tend to save you time by providing binaries, but that's simply a time-saving measure. It's not even guaranteed that your Linux system is an x86 system, so there's really no such thing as a "Linux binary". That's more of an option on unix machines that have fat binaries and limited platforms, like OS X.
In essence, a binary is never future proof. Source, and even more so, algorithms and specifications, are.