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?

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.

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