Main Linux Distros Port To IBM's S/390

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??

Comments

What do I think?

[FascDot Killed My Pr]

If you give me a free S/390 I'll do a review for you...
--
Have Exchange users? Want to run Linux? Can't afford OpenMail?

Re:Linux on IBM

[Jeff Mahoney]

Granted I don't work for IBM, but I'd hazard a guess there isn't a snowball's chance in hell of that happening.

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.

This is wonderful!

[Loundry]

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:This is wonderful!

[jms]

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

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 /usr/include.

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.

You're forgetting something

[delevant]

This Linux port is not, generally speaking, intended for day-to-day JCL stuff. Nope. IBM wants ISPs to buy a single S/390 to run their server farms.

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.

Linux on the S/390

[Dr. Sp0ng]

The S/390 is a big mainframe, correct? If so, then Linux on that thing is phat. Not as the main operating system, of course - but as another operating system running on the same machine. That's what so cool about these things - you can run several operating systems at the same time on the hardware. So you could have the main OS serving up huge databases or whatever and then have Linux with Apache serving up web pages, Samba serving up shares, etc. I want one.
--

Re:Linux on the S/390

[mrBoB]

dude, did you read that article from linuxplanet awhile back? Twas awesome! If you thought that article was awesome, check out this sweet piece of hardware.

I think you forgot...

[Cee]

The only major distributor that is missing here is Redhat.
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.

Re:Who cares?

[Black Parrot]

> Apart from a few academics running dinosaur equipment, who cares?

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.

--

Re:Who cares?

[finkployd]

Apart from a few academics running dinosaur equipment, who cares?

I'll bet you think large companies do all their computing on PC's huh?

You'd be shocked to find that these machines are still being made, keeping up with the latest technology, and faster and more reliable than the best cluster systems.

Finkployd

Software available too.

[Black Parrot]

At Linux PR you can read a bit about the e-commerce apps coming out for that environment.

--

Slackware port for 6502

[Anonymous Coward]

Following the recent announcements that SuSE and TurboLinux will be releaseing Linux for the IBM S/390 and RedHat's release for the Itanium, Slackware have announced a release for the Commodore 64.

"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