Main Linux Distros Port To IBM's S/390 200
SuSE has announced that they are going to release a beta SuSE Linux for IBM's S/390. A beta version will be out in late June. TurboLinux has signed an agreement to port their Linux distribution to S/390 as well. The only major distributor that is missing here is Redhat. What do you think about Linux distributions and the S/390??
Sweet (Score:1)
Linux on Mainframes (Score:1)
The S/390 is a superb, multi-user, highly secure stable machine; very scalable and powerful.
Linux is very popular and getting ever more so with Microsoft's security faux pas; it is fairly stable, and fairly secure so people are turning to it in droves for database/app serve/web serve type uses.
Put the two together and you get a powerful machine, which is no longer esoteric and scary. It becomes more 'everyday' and easily accepted. Okay, this will lower the average salaries of an S/390 tech, but it will open up the S/390 to companies who wouldn't have thought of it before.
Oh, and sources at IBM say Red Hat is working on it.
The Parking Lot Is Full [plif.com]
Re:Who cares? (Score:2)
However, I still care. This is really neat stuff. It tells me stuff about Linux, Linux kernel hackers, and IBM that are all good to hear. Just knowing that people are using Linux in this way, and that it works, is something I care about.
There are plenty of things which I care about that have little or no practical use to me. I'm probably never going to go to Mars, or other planetary systems. I still care about the research being done on them. I may never visit South Africa, or buy anything made there, or know anyone who lives there. But I'm still glad that the ANC won without a bloodbath. Only someone with no empathy or imagination would think that only those directly affected can care about something.
Re:Ok, Ok, I'll do it... (Score:1)
Re:Linux on IBM (Score:1)
Obligatory Disclaimer: I do work for IBM, and I am not representing the company or any part of it ... just speaking my own mind. Sheesh. :)
You might be surprised.
IBM announced some time ago that Linux compatibility was going to be added to AIX. While this may seem kinda backwards - I think it would be better to just make AIX fully Linux compatible, or scrap it entirely and run with Linux, period - it's an important signal of general acceptance of what's been called 'a college project gone horribly right'.
Don't forget, IBM's been in the computer business longer than pretty much anyone else (if someone's older, I'd like to know who), and nobody learned a lesson the way they did about trying to dictate market terms -- remember Microchannel, or the PCjr? Sometimes the best lead can be taken by following along a while and seeing what happens.
What I think we have here is not that there's an expectation that companies will ditch MVS in favor of running Linux on their S/390s, it's that companies that had no use for Big Iron with a cryptic and user-hostile OS may have use for Big Iron with a widely-distributed, widely-supported and widely-understood OS on it. After all, it's better to sell a nude S/390 than to not sell a fully loaded one.
ikaros, who, being a lowly field tech, does not have access to top secret marketing plans, but this sounds rational to me.
only if apps get ported... (Score:1)
Re:What about IBM's BEST hardware? (Score:1)
With repect to the topic at hand I personally don't play with s/390s on a daily basis busis but allowing your mainframe (if you already have one for your SAP/Peoplesoft stuffs) to function as a web server as well is smart strategy in leveraging existing resources. Bringing linux to the high end computing market is probably important than some of the other features we linux freaks has been clamouring for because those computers have sufficient omph to do mission critical apps.
By the way I want a s/390
Re:only if apps get ported... (Score:1)
Mr Thornton addresses the compatibility issue by pointing out emulation engines (Hercules at http://www.snipx.freeserve.co.uk/hercules.htm) and saying that "Linux on the S/390 is just as much Linux as Linux/PPC, Linux m68k or Linux/Alpha...its the stock kernel, rather than a subset or extension...if it comes with source, (chances are) your can build and run it with minimal effort." Then he talks about "Think Blue Linux and the "Iron Penguin" and the fact that they have 420 RPMs running for binary installers.
Now think a Beowulf cluster of 50,000 machines, installed in an hour, with each machine having available a minimum of 550Mbps PPP comm channel between the machines. Shared memory is no problem (think
What was your question?????
Re:What do I think? (Score:2)
Re:You're forgetting something (Score:1)
Re:Doesn't say it's a guest OS (Score:1)
runs in LPAR - done that, too. And it runs as a
guest under VM - do that all day every day. It's
good stuff.
Linux on S390 is an ASCII machine - USS under
OS/390 is EBCDIC - that's often a nightmare when
trying to port software - ask me, I know - it's
my day job!
Linux on S390 supports ext2fs. It's reasonable to
expect there will be a CMS filesystem driver some
day as well.
All in all, Linux on S390 is pretty darn good.
Actually, no... (Score:1)
Marist College and Princeton University did it first. I don't know where Dr. Vepstas (the guy who did it in a lunch hour) teaches, but I don't think he's an IBM fellow.
IBM arrived to this, like Apache, late. However, they saw the value in how this was done, saw it worked and decided (rightly) not to screw with it.
IRON PENGUIN FOREVER!!!!
http://linux.s390.org/
http://linas.org
Re:Linux on IBM (Score:2)
Re: (Score:2)
Re:Linux on IBM (Score:1)
Re:Redhat on IBM (Score:1)
Re:Looks like (Score:1)
Who'da thunk it? (Score:2)
I work on a fairly small mainframe (oxymoron) running OS/390, programming COBOL on loan systems on a small co-op bank--I've got a PII/450 running W98 on my desk that only gets used as a 3270 emulator (and Web browser when the boss isn't looking). There's nothing new, sexy, or "hip" about S/390 mainframes, but they are dead solid reliable. They just don't break.
So of course our CIO is hellbent on scrapping our ugly but functional COBOL-based systems for the Brave New World of client/server, VB 6, SQL Server 7, Microsoft everything, distributed processing, blah blah blah. Forget what works, it isn't New! and Improved! so we dump it and go for eye candy. This is why I like seeing stuff like this--keep that super-reliable raised-floor gear but bring it forward into the 21st century, or at least the mid-90s.
This sure seems like the best of both worlds--mainframe reliability and *nix flexibility. Now, when the heavy iron operations people meet the Linux geeks, that is gonna be fun...
how big are these things? (Score:1)
IBM support is far more significant (Score:2)
Re:What do I think? (Score:2)
Even an S/390 emulator might run Linux at reasonable speeds, if you run the emulator on a modern PC or workstation.
Which distro - why not all of them ! (Score:1)
Having thousands of concurrent Linux boxes running offers another option. Web server software to date has been developed on the basis of multiple users using a single server. OK, there is load balancing, but this doesn't alter the paradigm, it merely loosens a few of the constraints. The S/390 opens up the option of each user connected to the site having one (or more) virtual Linux boxes of their very own to process their transactions (or whatever). What could your e-commerce site do with that ?
Re:Linux on the S/390 (Score:2)
Yeah, that is pretty damn cool, but not terribly useful. I think it would be much more useful running under a virtual machine. Linux just can't possibly take full advantage of that hardware, what with all the billions of CPUs (err... maybe not billions
I'd love to see some performance specs on Linux vs OS/390!
I'm sure it would get creamed. Except for Intel chips (maybe others too, but I know not Alpha or PPC), Linux is generally not as fast on the hardware as operating systems which were designed specifically for that hardware.
On a related off-topic topic (?), does anybody know if Compaq is still doing that free Tru64 for personal use thing? I'd love to give that a test drive on my Alpha (or, if nothing else, just steal the math libs and compiler to run under Linux with the Tru64 emulation libs
--
Re:Slackware?! (Score:1)
Linux rocks!!! www.dedserius.com [dedserius.com]
Re:What do I think? (Score:1)
I've got three-phase in my house, don't you?
Doesn't say it's a guest OS (Score:1)
Re:Why? (Score:1)
Wow, everybody does Linux! We should not stay out of this. We should do some Linux too. Let's close this project, this and that, then spend $x.xxE6 on this and see.
Re:Linux on IBM (Score:2)
Heh, just call me picky today... :-)
It surprises me how most people don't remember that VMS was born on the VAX architecture. Not too different from the folks who think that PCs started with Pentiums. I'll concede that it was more of an oversight or omission than an error.
Methinks you're referring to an older version of VMS. It's had a journaled filesystem (the Spiralog file system) since v7.0 or maybe the later v6.x releases (if memory serves). Don't ask me about it though; we never used at the last VMS site I worked at though I know some people swear by it (while others swear at it). It's not IBM's jfs, DEC's advfs, or whatever Veritas's is called but it's not really FAT-like either or so I understand. Now Files-11 is/was sort of FATty but I've never actually had a corrupted file on a File-11 disk while I've had, and seen countless other people have too, plenty of experience losing files on FAT-based filesystems (via the infamous cross-linked cluster problem). I suspect, though, that most of those losses were due to essentially being root on the PC when using DOS/Windows and its propensity to crashing. If I ran around on VMS systems with BYPASS privilege turned on all the time, I would expect more problems.
As for the drive letters: I never found the drive naming to be a problem. It was tons better than PCs had at the time. I suppose it depends on whet you used first. Personally, I'd find it somewhat annoying to go back to drive letters nowadays. In fact, I currently find it annoying as hell that Linux still uses sequentially assigned drive letters in the SCSI subsystem when other, more transparent, naming conventions exist (especially, since I was using a PC UNIX in the early '90s that didn't have this limitation). One wonders why the kernel developers seem to hate the way System V handles SCSI devices. Oh, well.
Just what are the complaints about Compaq's hardware? I've never heard anyone complain about the VAX and Alpha hardware before other than about the price. Now Compaq's PC hardware? That's another story and I do know of techs who will say it ``bites''.
Not sure what you're driving at with this comment. What kind of ``cluster'' is this, I wonder. It sounds like you mean hardware fault tolerance. Buy a Tandem or a Stratus. They're hard to beat FT-wise. Of course, you gotta have some pretty deep pockets to consider those hardware platforms.
rtscts? Gee, I'm still getting by with xonxoff.
--
Um, Debian? (Score:1)
Re: (Score:2)
Re:Bridging the skills gap, apparently (Score:1)
Most 390s are probably still running old COBOL stuff, that's my guess. And the knowledge pool for that old software is drying up. So if a business can keep that monster humming in the basement and shift to a "modern" language, thus allowing them to recruit new talent...hey, why not? And maybe they can teach a couple of the new guys some COBOL to keep the old applications running until they can be ported over. :)
Try it, you may like it (Score:1)
and samba all compiled fine.
It looks mostly like linux on intel - configure
can barf when it sees *-s390-* as the host
to configure against but thats an application
configuration problem, easily worked round.
Re:Linux on the S/390 (Score:1)
What do I think? (Score:5)
--
Have Exchange users? Want to run Linux? Can't afford OpenMail?
Re:MHz aren't everything (Score:2)
You are right, Mhz isn't everything. For the 390, it is fairly telling. I don't recall any superscaler implmentations. I don't beleve it has a fused FP multiply and add. For FP it just isn't all that fast, nor even for 32 bit integer math. On the other hand it's BCD math can be quite fast (single instruction for most ops, something like 40 or 60ish digets supported in hardware, more possable with OS assist). Translate table instructions.
If it's I/O you need fast a 390 can do it. If it is something else you need fast, there is almost certonally another computer that will do it better. Frequently even made by IBM :-)
For FP Fortran code, I would guess a Alpha would really run much faster (in absolute terms, or per dollar) then a 390, unless you have quite a bit of I/O going on. Even then maybe. I'm sure Compaq has a F90 compiler.
Of corse the 390 is very very very good at making sure that the answer you get is right. It's somewhat fault tolerent, but more importantly for many applications it actaully notices many kinds of breakage and will let you know about them rather then blondering on with the wrong answers.
Oh, goodie! (Score:1)
--
Looks like (Score:1)
Linux Counter (Score:2)
At this point there are 76148 machines registered; one of these could increase this number by 50%!
Re:What do I thnk? (Score:1)
I can imagine some really big clusters.
However, I will grant that there's a great many computational problems that don't parralellize that way, and some of those it may very well be impossible to build a cluster that's faster than a top-end mainframe (or supercomputer).
All depends on your workload...
Re:Linux on IBM and NT on Unisys (Score:1)
I have had some experience with IBM AS/400's and I know that they are rock solid and I hear the same things about the S/390's. I don't know why you wouldn't run a VM Linux session to at least check it out. There are a lot scarier things out there than Linux on mainframes!!
Linux on IBM (Score:2)
I wonder what the banks will think of that?
Re:Linux on IBM (Score:1)
Re:Linux on IBM (Score:1)
--
Why? (Score:2)
Re:This is wonderful! (Score:1)
Debian - One distribution to rule them all (Score:1)
It's an administrators dream.
S/390 and Linux (Score:1)
Re:Slackware port for 6502 (Score:1)
http://www.choin.netsurf.de/~dallmann/lunix/lng
Lunix for the Commodore 64 and 128.
Who's going to take the risk? (Score:1)
Re:Slackware port for 6502 (Score:1)
SuSE must have taken in account the possibility of running 1000's of Linux instances on every installed S/390 to decide if there would be enough users to make a port worthwhile.
If you allocate the equivalent of a c64 to each user, S/390 might very well surpass the i386 world Linux userbase.
I challenge you all to download the ISO in the name of Discordia. Fnord
I have a busy weekend planned (Score:2)
Re:Linux on IBM (Score:3)
From the few commercial UNIX vendors that have been offering Linux support - NONE, AFAIK, have announced any plans to migrate completely.
I've posted this before, but Linux just isn't there yet for the enterprise environment. Sure, some sites are deploying it in that environment, but major feature sets that enterprise users demand aren't implemented. Personally, I find admins that deploy Linux in a "mission critical" environment irresponsible [*] I've seen a few clustering packages for Linux, and quite bluntly - they all suck at this point.
I *am* a Linux user. I have been since 1995. But I'm also a realist, and an admin in the enterprise environment. While I might consider deploying Linux for a small non-critical system (like my workstation), I wouldn't dream of deploying it for "critical" applications.
Now IBM migrating to Linux on the S/390 is just an entirely different argument. Not only are you suggesting that IBM would migrate to Linux, you're suggesting that IBM would dump its huge investment in a specifically NON-UNIX operation systems strategy.
I know people that run S/390s with MVS, and I don't think they'd ever considering giving up the consistantly proven reliability of MVS for anything UNIXish. Indeed, that's not even a problem with Linux, but UNIX in general. (Yes, UNIX is reliable - but not next to a mainframe)
-Jeff
[*]: Unless they fake failover with something like the Cisco LocalDirector.
Demonstrates Linux scalability (Score:2)
RELIABILITY (Score:2)
On mainframes, no bits drop. (Actually, they do. But the mainframe fixes it and keeps on going. So as far as the software is concerned the computer is perfect.)
Now suppose you want to do a reliable web server for an enterprise:
- You could do a farm of PCs running Linux and Apache. But when a processor failes you lose the transactions in progress there.
- You could port Apache to (or write a web server for) an ordinary mainframe OS.
- You could port Apache to a mainframe Unix. (Has been done for UTS - Amdahl's mainframe SVR4. But while that will run on IBM mainframes it isn't from IBM.)
- You could port Linux to a mainframe. Apache and EVERYTHING ELSE UNIX/LINUX comes along for free.
Lots of other uses for Linux on a mainframe, of course. Mainframe reliability, capacity, and speed, combined with Linux reliability and functionality, is a powerful combination. But I bet enterprise-reliable web servers are the first "Killer App".
Re:Big Deal? No, but not for the reasons you think (Score:2)
MVS, while unpleasant at best, from a user's perspctive, has power roughly equivalent to an aircraft carrier. If you want to abuse that metaphor a little (and I do), maybe linux is the fleet of planes based off that carrier?
Anyway, we have some big iron here where I (for the next week at least) work, and there are aspects of it that rock nads. It's uber-reliable, and relatively low cost, in some respects. For companies that already use mainframes, this is simply beyond cool. We all know how well linux integrates with disparate systems. MVS is about as poor at that as linux is good, so this could be a piece which ties everything together.
Too Slow... (Score:2)
Re:how big are these things? (Score:2)
Depends on the "they" to which you're referring, and on what "quite large" means. According to the S/390 Multiprise 3000 Reference Guide [ibm.com], the "Base (CPC) Frame" for said machine is 520mm wide, 1110mm deep, and 819mm high, or 20" wide, 43" deep, 31.5" high for us Yanks, and, according to this page from the S/390 Integrated Server Technical Application Brief [ibm.com], that box is about the same size (533mm wide, 1038mm deep, 819mm high).
Re:Forked before birth? (Score:2)
No, of course not.
The same applies to Linux/x86, of course; let's pick the one distribution that should be the only one on x86. :-)
As far as I know, the "port", in the sense of "kernel, glibc, compiler, binutils (and perhaps gdb)" (i.e., the part of a Linux distribution that contains the most platform-dependent code - other than perhaps the X server) has already been done, just as it's been done for x86, Alpha, etc.; I presume what TurboLinux, SuSE, etc. will be doing will be combining that with their distributions to make S/390 versions, to go along with versions for whatever other processors the distributors in question support.
Big Deal? No, but not for the reasons you think. (Score:2)
This is wonderful! (Score:4)
I knew nothing at mainframes until I worked at a shop where one was used. Coming from a Windoze/UNIX background I was really really surprised to learn that there is this whole other mainframe universe in which there are many people working, coding, and living as if Windoze and UNIX didn't even exist. (Well, of course they're all aware of Microsoft.)
I got to learn a little bit about OS/390 (the operating system which runs on those mainframes) and it's a nightmare (in this UNIX bigot's opinion). lrecl, fb or vb, PDSes, GDGs, ftp commands like 'put BFDG.XD.DIWDOS(+1)', ISPF, fortythousand acronyms, gawd. From what I understand, IBM didn't even consider supporting TCP/IP until about ten years ago or so -- for a very Microsoft reason: they don't want to support any protocols they can't control (see also Direct3D vs. OpenGL and kerberos). There are several thousand supported instructions on IBM's assembler for OS/390. This is because there was such a huge number of assembler programmers for OS/390 IBM kept adding instructions to make programming easier. If I understand correctly, I think there is even a "print" instruction in OS/390 assembler.
90% of IBM's products =~ m|\w\w?/\d{1,4}|;
But the IBM of today is, what appears to me, a very different company. The prospect of running Linux on IBM is, in my mind, revolutionary for IBM. The prospects of Linux on IBM look really cool -- kind of like compacting hundreds of linux boxen into one big, black, airstreamed box with a big, red, candylike power switch that screams "Flip me!" So I think this is great. The more Linux, the better.
Re: (Score:2)
Re:Who cares? (Score:2)
Although Linux is an elegant OS with a bright future, at the moment it suffers from youth and the deficiencies of its original platform: the PC.
1. Raw I/O throughput. The strength of a mainframe resides primarily in its enormous capacity to move data through I/O channels. Separate I/O controllers handle most devices (like the I20 architecture), so the main CPUs are free to focus on computing tasks. The PC is not even in the same league--yet.
2. Advanced enterprise features, such as hierarchical storage management. Although Linux is moving towards LVM (Linux Volume Manager) to handle disk space, the mainframe data management facilities go one further: the OS will automatically migrate unused data from "small," fast hard drives to slower, larger hard drives, and finally to removable tape storage. This means that, unlike Linux where we manage mount points and disk partitions, the OS takes care of moving data around on all of its volumes to ensure best access. To the user (and an administrator), the sum total of all available hard disks and all cataloged tapes represents the complete collection of available data: terabytes upon terabytes of storage!
3. Another advanced feature: machine partitioning. Although incorporation of the User Mode Kernel is a step in the right direction, OS/390 (and high-end UNIX platforms, such as SUN, as well) allow an adminstrator to _partition_ a machine into completely isolated units, or partitions. Not to be confused with the Virtual Machine capability much discussed with Linux on S/390, but a partition is simply a fixed allocation of CPUs, memory, and I/O devices to an instance of a running OS/390 system.
What that means is 1 box may be split into multiple partitions, and each partition may have completely separate disk drives, memory, CPUs, etc. Basically, each partition becomes it's own machine, which can be useful for segregating activities onto different sets of resources (e.g., a test or development partition and a production partition). S/390 can do this because of hardware support, but unfortunately, efforts such as the User Mode Kernel do not achieve quite the same results: the "partitions" or "user mode kernels" still share the same underlying kernel data structures. If one UMK craps out, it could potentially bring down the whole machine.
Of course, give the Linux/Open Source community another 6 months, and it will solve all of these in spades.
Re:Linux on IBM (Score:2)
This is not to say Linux won't be good. However, reliability is one of it's big selling points and I'm not sure many of IBM's current S/390 customers will want to just hop into Linux when they already have a proven product.
Re:I'm not sure I understand this. (Score:2)
Meaning a native port of some flavor of UNIX, or S/390 Open Edition? If the latter, then you may already have given the reason:
meaning it may be easier to put Linux on an S/390 (or in a virtual machine or logical partition on an S/390) than to put some New Economy Dot Com applications on Open Edition.
General-register-based architecture, 16 general-purpose registers, 4 (or is it 8 or more, now?) floating-point registers, memory-to-register and register-to-register arithmetic instructions - not all that different from VAXes, 68Ks, x86's; it's just another general-register-based CISC box. (Yeah, it has specialized instructions, but so do the other CISCs for which GCC generates code; you don't necessarily have to use them.)
The relatively short offsets in instructions may be the biggest problem.
Linux has already been ported; presumably SuSE and TurboLinux will be integrating the kernel, glibc, GCC, binutils, GDB, etc. changes into their distributions.
There's been S/370 support in GCC for a while,a s I remember; the S/3x0 config directory of the EGCS source [gnu.org] includes notes and checkins that suggest support (e.g, the 1.3 version of the README file [gnu.org] says that it currently "supports three different styles of assembly", including MVS using the HLASM assembler, S/390 Open Edition, and "ELF/Linux for use with the binutils/gas GNU assembler".
There's also, in the GAS CVS tree [cygnus.com], tc-i370.c [cygnus.com] and tc-i370.h [cygnus.com] files (which are for S/360 and S/390 as well as S/370, according to the comment).
Re:Too Slow... (Score:2)
Just my .02cents though
send flames > /dev/null
Is there a market? (Score:2)
And then, since it is mainly GPL software, you could buy just one copy (disc? tape?) of a distro and install it in all the virtual machines of all the mainframes in the company. So you have a maximum number of sales as big as the number of Data Processing departments that run S/390s. I expect this number to be small, at least, compared to the number of individual-owned PCs.
So I think that the number of sales of these distributions has to be very low (comparing to PC distros). And media sales is the main revenue of distribution makers.
Am I wrong?
__
I'm not sure I understand this. (Score:2)
At my job I spend a lot of time working with IBM's Open Edition, which is a UNIX that IBM implemented on top of os/390. It is very, very strange as UNIX goes. A lot of common things you associate with unix aren't there like a password file, and other common facilities. Things are put in very strange places on the filesystem, and the way the backend works, (i.e. how it interfaces with MVS) is far weirder than weird. That said, it's a very interesting system that seems pretty stable.
Unfortunately, none of the architecture dependant GNU utilities will compile on this beast, since the hardware isn't even similar to anything unix boxes are used to running on. If suse is going to port linux, they may encounter the hardest part in porting things like gas and gcc, since AFAIK they don't know how to spit out binary for this CPU as of now.
(FYI for people who aren't familiar with OS/390 - it's IBM's mainframe OS. These types of boxes generally start in the $60,000 range for one that probably isn't worth using, and range in price up to the multi-million dollar range. On the one I work on, each individual CPU costs $200K.)
That's why I say probably most slashdot readers won't care. For the vast majority of people, they never work with a mainframe because the only people who can afford to have mainframes are large organizations. (The federal reserve has some bitchin huge mainframes)
Re:One swallow maketh not a summer... (Score:2)
Molog
So Linus, what are we doing tonight?
Re:Who cares? (Score:2)
However, valuable as UMK is for some applications, it's (yet) not in the same league as mainframe partitioning.
1. The OS and system software on mainframe partitions may be upgraded separately without affecting other active partitions. UMKs, too, can be upgraded, but if the real kernel has to be upgraded, the whole machine goes down.
2. How well does the UMK protect the underlying real kernel (and thus other user-space apps) for excessive resource consumption? For example, what if an errant application running in an active UMK (or just buggy code in the kernel used by the UMK) starts spawning threads like crazy, will the UMK protect the rest of the real machine from adverse effects?
3. The UMK kernel, valuable as it is, is still limited in it's ability to differ from the true underlying kernel. For example, can a kernel within a UMK provide a different thread-scheduling policy that the underlying real kernel?
BTW: don't get me wrong, I love UMK and what it can become. It's quite an accomplishment to put such a thing together. Further, I may be incorrect about the completeness of it's operation. However, my whole point is to emphasize how in IBM's mainframe environment complete isolation of distinct partitions is very easy, and it's a feature that the Linux commmunity may wish to emulate as it moves further into enterprise computing territory.
Re:Who cares? (Score:2)
They arn't so much faster and more reliable then the latest cluster systems so much as actually being the latest cluster systems. Oh, and being far more reliable (lots of check logic, ECC on the cache, and register files, not just main memory). Not so much the faster part though. The CPUs only run a few hundrad Mhz (last year 300Mhz to 400Mhz was extreamly fast for them). Of corse they have dedicated IO processors, and small tens of CPUs is a common size.
Most of the innovations in clustering in the micro world is re-inventing what mainframes have allready been doing. Then again so was having caches, and out-of-order execution. That's not to say micros didn't invent something, or that finding the right time to re-use what had gone before isn't hard in and of itself.
You're forgetting something (Score:3)
Your basic S/390 can run 200-300 Linux server images under VM. Taking the usual uptime and hardware failure figures into consideration, these 200 Linux "servers" will be VASTLY more reliable than the equivalent "real" Linux servers. In any large hosting environment, you've got machines crashing hard every week -- the MTBF really comes back to bite you when you're dealing with hundreds of physical units.
IBM doesn't think anybody in the world will go replace MVS with Linux. They're trying to grab the hosting market. Don't forget, when we talk about running 200 Linux servers, they're not talking about 200 hosting accounts -- they're talking about the equivalent of 200 actual servers, each of which would have bunches of hosting accounts on it.
Nobody is going to switch their bank transaction stuff over to Linux. IBM's just aiming for Sun. Besides which, I'm sure they're thinking about eventual transitions, etc.
. . . of course I could be wrong.
I doubt debian will port... (Score:2)
(I hope I'm wrong about that. Debian kicks ass)
Re:Linux on the S/390 (Score:2)
Hmmm.... well, that's an idea. Although I'd still like to try Tru64.
--
What do I thnk? (Score:2)
Let's celebrate!!!
--
Here's my mirror [respublica.fr]
It's ISP hosting (Score:2)
Instead, they want an ISP to buy a 390 and pop a couple hundred Linux "servers" on it, each with their own wad of hosting accounts.
This might actually make sense, as if you're running a truly gigantic hosting farm then you're probably getting bit by MTBF on a regular basis. Using the 390 would significantly reduce your exposure to outages etc.
Now, since each Linux image would be a "real" server, even if it didn't exist in the physical world, the ISP could use their normal admins etc. -- they'd just need to hire somebody to run VM for them.
This way they can run monster hosting farms on reliable hardware, probably save a fortune in power requirements (one 390 vs. 300 PC-level boxen), and they don't have to all start learning VM or MVS.
It's obviously not for everyone, but I really do think it might be useful for lots of companies that wouldn't otherwise even think about mainframes.
Linux on the S/390 (Score:3)
--
Debian? (Score:2)
Does Debian have a proposed port? I'd love to load up Linux on my S/390 here at home... *dreaming*
eraseme
I think you forgot... (Score:3)
And Debian is not a major distribution? I think you should be a bit more impartial in your comments. "The only" is a quite strong expression.
One swallow maketh not a summer... (Score:2)
I'm only playing Devil's advocate, but this sort of logic is only a small step away from that of people who think RedHat==Linux.
Re:Who cares? (Score:3)
Actually, mainframes are quite rare in academia, unless you want to count the registrar and business office. They are found most commonly in business environments: banks, corporate payroll systems, etc.
--
Comment removed (Score:3)
Re:This is wonderful! (Score:4)
I don't think that was why they ignored TCP/IP for so long. IBM wasn't playing the undocumented protocols game at the time, at least not on their mainframes. You can order manuals from IBM that exactly describe each and every detail of their communications protocols -- enough information to actually implement the protocols, and there were third-party hardware vendors who did just that.
The issue with TCP/IP was more likely that it's a very CPU intensive protocol. It kills your performance. TCP/IP peppers the processor with a constant stream of little interrupts for each packet, and the internal design of OS/390 (and VM also) is optimized for a small number of interrupts that each do a lot of work. For instance, you can tell the hardware to scatter-read 200 blocks from disk into non-consecutive memory, then generate a single interrupt when finished. IBM terminals are designed so that the terminal buffers everything you type until you press the send key, then the terminal creates a single data stream that describes all the changes you made to the screen data, and sends it all at once, generating a single interrupt.
It works a lot like slashdot. I'm typing away in the Comment window, making lots of changes as I go, but I'm not echoing each character off of the slashdot server. Instead, when I press preview or submit, everything I've typed is forwarded at once.
The heavy interrupt rate of TCP/IP is a big issue. The main reason that a mainframe can support thousands of users, all sitting at 3270-like terminals, is that most people tend to spend their time doing things like moving their cursor around the screen, backspacing, using the arrow keys, and typing a lot of text, only pressing enter/send occasionally. When you're using ordinary telnet over TCP/IP, each time someone presses a key, the CPU is interrupted, has to wake up that user's editor process to handle the incoming character, and most likely echo the character back out. When you are using a 3270 editor like XEDIT, you can busily type an entire page, moving the cursor around the screen, inserting and deleting text, all the while your user process is completely idle -- maybe even swapped out -- on the mainframe, until you press return. This lets mainframes support much larger numbers of interactive users and TCP/IP would have broken that.
Back then, IBM had their own networks, and they were all running mainframes and mainframe networking protocols. Educational sites like ours were mostly on an IBM hardware network called BITNET with some cool features of its' own, (we had instant messaging in 1982!) and TCP/IP just wasn't important. The internet hadn't become important yet, and no one would have even considered degrading their mainframe performance by adding a TCP/IP stack, unless there was a damn good reason, and there wasn't. IBM had devised more efficient protocols, optimized for their hardware model, and everyone was using them.
One of the "features" of unix-like systems is that the TCP/IP stack is buried in the kernel, and the TCP/IP overhead is buried in the kernel overhead. On VM, the TCP/IP stack runs as its own process, and shows up in the process list, so you can see just how much of your CPU is being wasted on receiving and reassembling packets. It's a lot.
When IBM finally started seriously supporting TCP/IP, they had a lot of trouble getting good performance, because it breaks their interrupt model. One of the products that came out of that was an outboard TCP/IP coprocessor -- a dedicated PC with an ethernet card and an IBM channel card. The PC would receive data from the ethernet, reassemble the packets, batch them up, and present a bunch of them to the processor at once, reducing the number of interrupts. TN3270 also helped -- TN3270 does what the 3270 hardware did -- buffers all of the user's screen changes, and keeps track of the cursor, lets you do inserts and deletes, and sends a summary of all the changes when you press return.
IBM's spent more time and effort on their TCP/IP stacks now that they have become more important.
There are several thousand supported instructions on IBM's assembler for OS/390. This is because there was such a huge number of assembler programmers for OS/390 IBM kept adding instructions to make programming easier. If I understand correctly, I think there is even a "print" instruction in OS/390 assembler.
The 370 instruction set is a fairly standard instruction set. It does have a handful of really oddball instructions, but certainly doesn't have thousands of instructions. What you are describing are the macro libraries. The traditional programming language for the IBM mainframes is and has always been 370 assembly language. The operating system provides extensive assembler macro libraries, and when you are programming, you use those macros in-line, so they look like instructions. There's an entire, fairly powerful programming language just for writing macros, because they are used so heavily by application code.
But describing the contents of all those macro libraries as instructions is like decrying the C programming language for having thousands of instructions like printf() and strcpy(). Those macro libraries are the equivalent of the ".h" files in
Yah, there are a lot of acronyms. If you thought you had a lot of macro names to keep track of, you should have tried a little VM internals programming. There is a two-volume, 1500 page book with dense text, describing tens of thousands of eight character macro definitions and equates like "VMDIORBK" and subroutines with eight character names like "HCPDSPCH"
Why?
It took IBM until the 1990s to release an assembler that could handle symbols with more then 8 characters.
Back in 1993, I downloaded whatever the latest Linux kernel was at the time (0.99pl10, I think), and just for grins, ran the IBM C compiler against the source. It truncated all of the function names down to 8 characters, and of the modules that did compile, the load module had over a thousand duplicate symbols. I started writing a huge macro with entries like:
#define insert_vm_struct MMINSVMS
to map each and every function name down to 8 characters. Eventually, I gave up in disgust. I knew that it wouldn't have worked without a huge amount of rework, but I just wanted to see how hard it would be to get a clean compile. Never got one.
System V on Amdahl S/370 Clone A Long Time Ago (Score:2)
It wasn't perfect - getting backspace-echo to work well on that sort of I/O controller just wasn't going to happen - but it was pretty close, and you could at least use vi. I was taking a compiler course at the time, doing a lot of compilation, and the choice of timesharing a Vax with ~40 people or using the Amdahl with ~2 people was pretty obvious
Why would you port Unix to Big Iron? Well, not only could you use the blazingly fast 10+ MIPS of CPU (when Vaxen were the canonical 1 MIPS), but more importantly, the distributed I/O architecture lets you do immense quantities of disk I/O to run databases. Not only is this Entertaining Research, but it was valuable for phone company billing and equipment-configuration-management applications, allowing more flexible Unix development environments, and it was a much better development environment that Vax-sized machines for the 5ESS phone switch development folks, who needed to compile and build programs that were huge then and large even today.
On the other hand, fsck took a *long* time to run, since the machines had a lot of disks, and this was back when Unix file systems really did need to be checked every time you booted
Re:Who cares? (Score:2)
> efforts such as the User Mode Kernel do not
> achieve quite the same results: the "partitions"
> or "user mode kernels" still share the same
> underlying kernel data structures. If one UMK
> craps out, it could potentially bring down the
> whole machine.
Wrong. If one umk craps out, it affects nothing else. Every umk has its own data structures, completely separate from every other kernel on the system.
Jeff
Re: (Score:2)
Re:Why? (Score:2)
Many companies have a huge mainframe investment. They have a lot of money tied up in the hardware, software, and data onboard. Other companies just starting up find that their bandwidth actually requires a mainframe--think of an online stock brokerage or online bank.
Unfortunately, it is really hard to get mainframe people--admins, programmers, and the like. It's a relative cakewalk to get Unix/Linux types.
Linux on the mainframe allows easy access to the mainframe bandwidth and the data already there, as well as better access to a techie base.
Think of it this way: you are running a trading firm (already using a mainframe for trade databases), and you want to become an online trading firm. You need a very powerful web site that can handle heavy bandwidth. that site needs to be able to communicate with a slew of online users (so many that your network guys are installing a T-3 rather than multiple T-1s), and it needs to hit that mainframe database, fast.
Install Linux on that mainframe, compile Apache on it, and build your website onto the mainframe. The web site is now on a machine that can take full advantage of a T-3, and will access the database within the same machine. Effectively, your database connection is TCP over loopback. Finally, you can attract really good sysadmins, programmers, and Web designers because it's easier to find Linux talent than OS/390 talent.
UNIX beats big iron (Score:2)
This used to be true, with I/O devices directly connected running at channel speeds. However with the advent of cross-bar technology and SANS (12.6GB/s on a Starfire and 100MB/s full duplex disc access using fibre) it is true no longer. A big UNIX box can beat the pants off a mainframe in terms of CPU, I/O and cost.
Where UNIX doesn't come anywhere near the mainframe is in handling a complex workmix and availability. These are the major reasons why you find enterprises running online transaction processing on the mainframe and datawarehousing on a cheaper, more powerful box.
Re:I doubt debian will port... (Score:2)
http://www.debian.org/News/weekly/2000/15/mail#
Quite a good paragraph from it says...
"I've found many friends of Debian within IBM. Debian is seen here as a well respected, high quality distribution. A debian-s390 distribution also seems to fit well with the idea that IBM just doesn't want to be in the distribution business."
There's a mailing list at debian-s390@lists.debian.org and a site at http://pax.gt.owl.de/~higson/debian-s390/ if you're interested.
Debian just gets better and better!
Re: (Score:2)
Re:Used to be able to (Score:2)
IBM's always seems to have had things like this. Anyone else remember the 370 emulator for the XT that even let you run a version of the VM/CMS operating system on your desktop. (We were a big CMS shop back in those days and I lobbied to get a couple of these cards but they were much too pricy for us.)
--
The Blue Devil is my Best Friend now (Score:2)
Running Linux on IBM mainframes in their virtual-machine "userland" is nothing new in itself (was noticed on
Software available too. (Score:3)
--
Slackware port for 6502 (Score:5)
"It just seemed logical to go for a machine with a huge userbase." Said a spokesman with a funny last name who was probably called Rob or something. "Linux scales remarkable well to small machines. In fact much better than it does large servers."
Critics of the company are sceptical about whether the system will be reliable since it comes on tape.
"I just used the CD record feature on my stereo" said Rob. "It works for music so why not data?"
When asked whether a spectrumversion would be available, Rob said "It all depends on the success of this version. We're hoping to port it to all Z80 based machines, and possibly even pre-electronic machines".
Charles Babbage was not available for comment
Re:Linux on the S/390 (Score:3)
Re:Debian? (Score:2)
Re:Who cares? (Score:2)
> However, valuable as UMK is for some
> applications, it's (yet) not in the same league
> as mainframe partitioning.
True enough. I never claimed I was creating the next VM.
> UMKs, too, can be upgraded, but if the real
> kernel has to be upgraded, the whole
> machine goes down.
Yup. But if you ever have a setup where essentially everything is inside a UMK, and the hosting kernel is stripped down to the point that it's just providing processes, device drivers, and a filesystem, then you can run that forever, and just upgrade the UMKs.
> How well does the UMK protect the underlying
> real kernel (and thus other user-space apps)
> for excessive resource consumption? For
> example, what if an errant application running
> in an active UMK (or just buggy code in the
> kernel used by the UMK) starts spawning threads
> like crazy, will the UMK protect the rest of
> the real machine from adverse effects?
The UMK, just like a native kernel, runs in a constant amount of memory. You configure it with 64M, that's all it will ever use. You configure it with 4 processors, it will never have more than four processes running at once. So, you can protect the native kernel from excessive resource consumption by sticking things inside a virtual machine.
> The UMK kernel, valuable as it is, is still
> limited in it's ability to differ from the true
> underlying kernel.
No it's not.
> For example, can a kernel within a UMK provide a
> different thread-scheduling policy that the
> underlying real kernel?
You seem to think that the UMK is somehow not a full kernel. It is. The underlying kernel is just a provider of resources. If a new version of the kernel provided a funky new scheduling policy, UMK would support it, regardless of what is supported by the underlying kernel.
> However, my whole point is to emphasize how in
> IBM's mainframe environment complete isolation
> of distinct partitions is very easy
Yeah. Nothing comes close. Not even Linux plus UMK. Maybe this is a small step in that direction and maybe some people will find that useful, but there is a long way to go.
Jeff
Re:Article in Linux Journal (Score:2)
The main debian S/390 porter at the point is not an actual official Debian developer. Debian is supporting him though, with a mailing list, &etc because such a port is a very cool thing.
Before such a port is actually blessed as official debian, it would have to be 100% free, which would mean it would have to use the fully free kernel port. However, pragmatically it doesn't make sense to force someone to wait until that is ready before they begin porting debian over to the platform
So in summary, debian is, and will continue to be, 100% free software. A correlary to that is that you may port debian to run under non-free software, like IBM's kernel modules, if you want to. Just like people who don't have access to mainframes can run it under the non-free vmware.
--
Re:Linux on IBM (Score:2)
Two errors in your post:
1. ``VMS is by Digital for Alphas''
You can still buy VAX architecture systems from Compaq (cringe -- I still have problems associating Digital's products with Compaq). The top of the line system is slower than most all of the current Alpha line (even the workstations) so I can't imagine who'd buy them nowadays though I suppose some organizations would have their reasons.
2. ``VMS sucks. I can't put my finger on why, but it just does''
You're wrong. My guess is that if you had any real experience with VMS it was on a poorly configured and managed system. I've always considered VMS and UNIX to be more alike than either of their most rabid proponents are willing to admit.
Funny how the state of the art in clustered systems is still a VMScluster (IMNSHO). Most of what the UNIX community calls clusters is really just a failover capability. Now that Tru64 has 99.44% of the functionality of a VMS-based cluster, including a common system disk, er, I mean, root filesystem, it should be assuming that title real soon now. What would float my boat would be if Compaq were to provide the details of how they do their clustering to the world so that Alan Cox could crank out a set of patches to provide Linux with this capability. Should only take him a weekend or so, right?
--
Re:Linux on the S/390 (Score:2)
Good article link, BTW. Somebody moderate that up.
--
Re: (Score:2)