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.
The impact of this will be impossible to measure!
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?
I know you're joking... but fuck, thoughts like that are damned scary
Support NYCountryLawyer RIAA vs People
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
The law of five:
An average X86 processor: $5000 (you get the box with it)
An average Unix Processor $25000
An average zLinux Processor $12500
IBM will be pleased to serve
That's a distinct possibility. It's something I have believed for quite a while...
I call complete BS. If you are 'at the mercy' of the mainframe admins, I seriously doubt that they purchased an IFL just for you to play with (they cost $125K), gave you access to the HMC so you can IPL the thing, but did not let you have input into the I/O setup. More likely they gave you a VM userid that you used to IPL Linux in, and you were competing for resources with a few thousand other users. Or maybe they were generous and gave you an LPAR, so you were only getting a portion of the machine (probably capped).
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.
So wouldn't you have to recompile all your apps to use it? Seems pointless - you may as well compile them for Linux - it's the same effort... and future proof.
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
I know you mainframe folks think they're fast, but, um...
They're not. There's no magic. They're expensive CISC(ish) chips running at 1.7-4.4 Ghz, depending on the model, and aren't much faster than you'd expect from that. Yes, they have well-above-average RAS features and bandwidth, but at $100K/core (ok, that's retail, you'll get a discount) it just doesn't matter; there are almost no jobs where they're cost-effective.
And yes, a new top-of-the-line notebook will very likely smoke a Z9 single-engine IFL on a random benchmark. The Z10 might make it interesting...
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."
Let me guess, your "tests" were based on you plugging into a single address space that was allocated to you by your mainframe group, hence you were only testing the resources your one session has been allocated.
That's hardly testing what a mainframe is capable of.. There were probably thousands of sessions running with the same allocations as your address space was.
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.
title says it all really
So, this is OpenSolaris, and there is a link provided for source code. But at the same time, the release notes state:
-------
IBM Restriction: Cannot Update Initial Ramdisk
IBM has requested that no source or other materials be included in the
distribution of phase 4. Without these materials, the initial ramdisk
and boot loaded contents cannot be changed, only rewritten to a new
minidisk.
-------
So, is this materials that are open source or not? I'm very curious why IBM would be requesting something as crucial as the boot loader and initial ramdisk to *not* be included in a way where source code can be investigated and/or modified, etc...
Maybe the original poster could at least have indicated that it's just not quite completely open source. Yet?
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
SUN did port Solaris to Power; I don't think it was released (the "ifdefs" were in Solaris 8).
The current port is OpenSolaris to z. No involvement of SUN. It was done "because it can be" -- the power of Open Source.
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.
please share your calculations for the rest of us
There is no Dana, only
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.
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.
So does the reliability of z come from the hardware or the culture?
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.
"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.