Linux on the IBM S/390

The atmosphere at SHARE 94 in Anaheim, California was nerdy beyond the ability of mere Unix hackers to imagine. Big draws at the conference, held March 5-10, 2000 at the Anaheim Hilton and Mariott, included sessions examining the latest updates to S/390 assembler programs and exhibits of computers the size of walk-in closets.


December 01, 2000
URL:http://www.drdobbs.com/open-source/linux-on-the-ibm-s390/184404406

Linux on the IBM S/390

Linux/390 in the Spotlight at SHARE 94

by Jack J. Woehr


The atmosphere at SHARE 94 in Anaheim, California was nerdy beyond the ability of mere Unix hackers to imagine. Big draws at the conference, held March 5-10, 2000 at the Anaheim Hilton and Mariott, included sessions examining the latest updates to S/390 assembler programs and exhibits of computers the size of walk-in closets. Attendees included over three thousand members and scores of vendors displaying millions of dollars of hardware and software. Evening wining and dining was grouped by tables manned by interest groups tracking particular applications such as MQSeries and REXX. White beards and suspenders abounded, identifying senior engineers, many of whom possess over thirty years of industry experience. One attendee, pondering the future of mainframing, opined that "our average age is over 50 years old," and wondered aloud about who is going to maintain these still-vital and mission-critical legacy systems when the current work force retires.

But the most popular attractions this year, inevitably filling meeting rooms to overflowing, were the sessions about Linux on the S/390. The air was electric with excitement about this revolution from below, which has drawn the world's largest intellectual property holding company, IBM, into communion with the open source community.

IBM representatives are pleased but obviously somewhat stunned by the attention garnered both inside and outside their customer base by a small collection of source diffs posted to an off-the-beaten-track web page. One cautious view among the managerial cadre is that Linux/390 may be a means to stem the decades-long erosion of interest in mainframe computing and draw mindshare back to this mature and stable field. Another faction has it that this debate had been settled inside IBM in the early 1990s when OS/390 Unix System Services became the officially designated solution path, and that support for Linux overturns stare decisus, undermining that which was assumed to be a "done deal" in the internal politics of the multinational IBM corporate city-state.

One indicator of the internal schism is that while IBM is trumpeting their open source Linux/390 work, one of the participants in the project is being menaced with disciplinary action for his unsanctioned but seminal role in the project, despite the fact that he did the work on his own time. There is every possibility that Linux/390 would never have been shown outside IBM had that organization not been goaded by the alternate certainty of an entirely non-IBM Linux port.

Although the OS/390 (formerly known as MVS) operating system, which serves the terabyte database needs of organizations such as the IRS and Bank of America, is the flagship of S/390 offerings, the minority VM/ESA community is home of the real metalheads in this crowd. They sometimes refer to VM as the "original personal computer."

VM evolved to suit the needs of the "real programmers," many of whom are as passionate about VM as today's young whippersnappers are about Java. While these enthusiasts know that for technical reasons VM will never depart the glass house, many worry that VM is generally receding from the landscape as a user operating system. They believe that the ability of individual users to run shared instances, personal instances, and application-specific instances of Linux/390 under VM will breathe new life into the old workhorse. We spoke with a select group of crossover VM-Linux/390 folks about this novel development.

DDJ thanks Marty Zimelis of Sterling Software for assistance in arranging our conversation. Thanks are also due to many other SHARE attendees who took time to chat with us about S/390, VM and Linux. Among these were Alan Ackerman, John Franciscovitch, Bill Bitner, Erich Amrehn and Melinda Varian. We also spoke with Linas Vepstas.

 

About Linux/390

About System 390

About Open Edition

About SHARE

About VM

About IBM's Corporate Evolution

A Conversation with VM-Linux/390 Experts

Do you have an opinion about what you've read here? Sound off in the discussion forum for this article.

Conversation at SHARE 94

Conversation at SHARE 94

Anaheim, California, March 7, 2000 — Jack Woehr sat down with a select group of crossover VM-Linux/390 folks about the genesis of this project. DDJ thanks Marty Zimelis of Sterling Software for assistance in arranging this conversation.

Participants:
Neale Ferguson, Sterling Software
Phil Smith, Sterling Software
Romney White, IBM
David Steinhoff, IBM
Stephen Record, IBM
Rob van der Heij, independent contractor
Rick Troth, BMC
Jack Woehr, DDJ


JW: How did Linux come to run on S/390?

RW: Through a series of fortunate accidents. Some people had an idea that it was possible, and they saw it through.

NF: There were a number of false-start attempts in the community.

Rick sent a number of notes about why you would want to, and it started to fall into place.

RW: Rick was talking about this almost ten years ago.

NF: It needs a critical mass. In one of the independent 390 efforts, there were people with the skillset who were Linux devotees who recognized that there was this thing called S/390, which all these Fortune 500 companies continue to run and that it might be interesting to see what Linux could do on this platform. Through luck and good fortune people had the skills to do the GCC compiler, the glibc, had enough familiarity with how Linux is laid out, its platform-independent parts, its platform-dependent parts, and a crew got on board and started to do the work.

I imagine it was the same case within IBM. People did things on their spare time, got a critical mass of very devoted people who like to share ideas.

SR: The IBM team started out with a need to have a GCC compiler that would produce 390 code. They were porting GCC to VM/CMS Open Edition [see sidebar, "About Open Edition"]. Having got a compiler that would generate that code, it then became obvious to them that there were things they could do other than what they had originally needed it for.

JW: The desire to port GCC to VM, which Neale, outside IBM, was already doing ...

NF: Attempting to do!

JW: ... Attempting to do, and there were some files in the GCC tree already aimed at MVS ...

NF: David Pitts did a damned good job, had GCC working under MVS. I had three or four goes at it, but had insufficient knowledge of the machine-dependent definitions to get much further than the phase-two compilation. Obviously the people at IBM had better skills!

RW: They started earlier and were very single-minded. They had this one key application that needed to be ported. Being able to compile Linux was an unexpected bonus.

NF: Were they Linux guys by nature?

RW: No, they were pretty much hardware engineers.

SR: They worked in hardware simulation, hardware performance. They're fairly young, so they had exposure to Linux, but it had nothing to do with their day job.

JW: What were they trying to build? Did they just want to say that GCC ran on Open Edition?

RW: They were trying to get away from reliance on a proprietary language, partly because you couldn't hire anybody who knew that language.

NF: PL/X?

RW: No, even more arcane than that.

NF: The microcode stuff.

RW: Yeah ... they were trying to solve an IBM business problem.

JW: So they wanted to actually use GCC to compile code for some part of the 390 system?

RW: Right. Then someone said, "You have GCC? Then Linux is a small step." A lot of the heavy lifting is in the compiler itself.

NF: Linux is nicely laid out so you can identify the system-dependent parts. With GCC, it's a major effort.

JW: Neale, you were porting GNU software to VM Open Edition before GCC was running.

NF: I ported SAMBA, Apache, and other killer apps, so the VM community didn't have to buy this sort of stuff. I wanted GCC because I wanted a C++ compiler, but I didn't have the skills to finish. I found David Pitts who had done it, and his web site pointed to Linas Vepstas who was working with Linux. The parts started to fall into place when people started finding each other. Rick found us again, Rob found us, Peter Schulte-Stracke in Germany ...

RT: Linas Vepstas had been doing big Linux for quite some time. He has a bit of a reputation lashing together 486s since before the Pentium. He's also done contracting on S/390, I don't know how much.

NF: He wanted to learn more about S/390. The best way to know an architecture to look at an operating system. So he took an operating system he knew and did some amazing stuff for a guy who wasn't schooled in the S/390 architecture. We came along and helped him with a lot of concepts we knew about from VM days. It was quite an amazing effort of the group to get as far as we did from scratch.

RW: It's to Linas' credit that, judging by what I read of the interactions on the mailing list [[email protected]], that he recognized what VM brought to the table.

RT: I believe he originally was doing this work without VM. I'm a metalhead, but not that much of a metalhead, to do all my testing with the actual hardware console. Having VM in there makes it much easier.

NF: Melinda Varian, from Princeton University, offered him an account where he could do all his kernel testing. That's where we all collaborated. I developed some debugging tools for him so he could do the tracing, see the page translation ... we really accelerated once we got onto Princeton and started using VM.

JW: You didn't know what was happening at IBM in Boeblingen, Germany?

NF: As large as IBM is, you can't help but hear the rumours coming out. We'd hear bits and pieces that indicated that something was happening under the covers. One of the nice things about the 370 stuff we were doing with Linux was hoping we could flush out IBM's hand by advancing. At every opportunity we were putting console logs on the list server to say, "We've booted this beast, we're getting a user process here." We were hoping IBM would say, "We had better mosey along, these people are getting a bit too far."

RvdH: Linas was pushing us to do it. I personally felt very awkward posting to the list seeing that there are 200 IBMers subscribed to the list lurking, knowing that if IBM wanted to do it, they could do it, that they have done it already and were just laughing at me!

NF: It was easy to tell Linas was working on it on his own time. He was corresponding at one o'clock in the morning, his time. It was good for me, because at that time I was in Australia. Rob would come on, again before and after work hours.

RvdH: Although I was embarrassed doing this on the list, Linas convinced me you should do this in the open. Just show the people.

JW: So did anything from IBM's internal project become public before the time everyone noticed it, in December, 1999?

SR: Last fall Karl-Heinz Strassemeyer, an IBM distinguished engineer made a presentation at WAVV, a VSE and VM worldwide user's group, in which he spent about a half hour talking about Linux.

JW: How did the decision take place that IBM was actually going to put this up on the Web?

RW: It wasn't an easy process; it was a lot easier to do the development work!

JW: Was there concern that the well was being poisoned with respect to Open Edition?

RW: Open Edition bring a lot more to the table than a bunch of Unix APIs. It was more a consideration of "how do we do this," because we have never done open source in IBM. We write software to sell to people. It was difficult for people to get their minds around the concept.

There are, to IBM, important questions about intellectual property relating to Linux and the licenses that surround it. We can't just cavalierly throw something out there and hope it will turn out all right. We have to understand these things.

DS: There was the issue of previous patents. For example, in porting DB2 to Linux, we had to consider how much of DB2 we could keep protected. This had to be thought through.

RW: And you'll notice that part of the "how" is that there's a network driver for Linux that is object code only, because it embodies IBM proprietary technology that we are not prepared to give away to the community.

JW: So as umpteen lawyers looked at this, you discovered that the GNU Public License is compatible with proprietary software plugged into it?

RW: I think what we discovered is that the GNU Public License is sufficiently ambiguous to make any attorney worth his salt incredibly nervous. Part of the problem was that it wasn't written by an attorney, so it doesn't use the terms of art that make lawyers comfortable. There are four or five places in the license that it is not terribly precise. If you don't know what rights you are giving up, that ought to make you nervous.

JW: So how does IBM grit its collective teeth and make such a decision?

RW: I think it's safe to say that there are several factors. One is the efforts by the customers. We knew that there was a race on, no question about it. We were also motivated by wanting very much to participate in the open source community, particularly with Linux, and stop having to keep what we were doing IBM confidential. Finally, it was the realization that it wasn't a matter of "if" Linux would run on S/390, it was a matter of when.

JW: And whose version. If IBM releases a distribution, that would become the canonical release to which most of your customers will tend to gravitate.

RT: What IBM has released is patches, patches to the kernel, patches to GCC, patches to GLIBC, GDB ... Based on those patches, which hopefully will get rolled in with the official sources ...

NF: I see from Alan Cox's change history the 390 changes are listed as 2.2.15.

RT: So it could be anybody's distribution. Red Hat may or may not compile it, but the sources that will be on a Red Hat CD will eventually have everything one will need to produce it.

NF: A company in Germany, Millenux, have put out their "Iron Penguin" or "Think Blue" release already, with 420 RPMs [RedHat Package Manager archives] ready to download [see sidebar: "About Linux/390"].

RW: Let's be clear about this: IBM has not made a Linux distribution for S/390 or any other platform.

JW: But you have empowered the community to create such a distribution.

RW: Definitely.

JW: At some point, isn't IBM going to want to take over the stewardship of such a distribution, in its own and in its customers' interests?

RW: That depends on what you mean by "IBM." I can find you an IBMer who will say no, and I can find you an IBMer who will say yes!

JW: Do things like this go all the way up to Lou before they get decided? How does the decision-making process work?

RW: We're discovering that as we go forward. [General laughter.]

DS: We might be just as comfortable having another open source distributor be our distributor, Caldera, Red Hat, whoever.

NF: I'm glad IBM didn't come out with a distribution as their first public offering. It allowed the community to have a look at the diffs, see what they did, build their own kernels, put a file system down, getting a hands-on feel, taking collective ownership. IBM put this thing here, and we've been able to embrace it, whereas if IBM would have come out with a full "Big Blue" distribution first off, that would have frightened a lot of people with "Thou Shalt" instead of "Here Is".

JW: That's the beauty of open source. Perhaps it appears to IBM that people are taking intellectual property, but they'll also do a lot of the work for you when you play as an equal partner in the open source community, doing testing, bug finding, general design without being paid to do it. Didn't IBM have much that same experience in the evolution of VM itself? Your users were perfecting your software for you, not because it was open source, but because they had source?

RW: I have to tell you, in the days when that was happening, I was a customer, and I'd say it was like pulling teeth to get IBM to actually adopt any customer software.

SR: It wasn't easy, but it did happen.

RW: Well, if you were prepared to give up all right, title, and interest in what modifications you had developed, IBM might have considered looking at what you had done. But it was a long, long way from the spirit of open source.

JW: Is open source an improvement for IBM and its customer base? Does the opening up of this gateway mark a new era in the relations of IBM and its customers?

RW: My personal opinion is that IBM has always made an effort to understand what customers want and deliver on that. At the same time, IBM needs to make a profit. Fundamentally, open source is a huge change in IBM's standard way of doing business. We're still digesting the effects of that, trying to understand what it means.

RT: Steps were beginning to happen prior to Linux. How long ago was it — eighteen months ago — when IBM made a contribution to Apache?

Was that to make it run better on Open Edition?

RW: We have a couple, I believe, of employees whose full-time job is to work on Apache. Of course, they contribute their efforts to the open source community.

JW: Why was IBM interested in working on Apache?

RW: Because customers are interested in Apache.

JW: Running on what?

RW: Almost anything. Apache was clearly the standard to aspire to.

JW: What was the change that made customers being interested in something you can't charge for make you devote employees to maintain this open source?

RT: I run Apache on AIX. Some people run Apache on Open Edition, some people run Apache on whatever IBM operating system they want to, and even if it's not an IBM operating system, it may be IBM hardware.

DS: So it's becoming a de facto standard. If you didn't support the de facto standard, you're either in the market or out of the market.

It's a simple decision we want to be in the market.

NF: It's not exactly a simple business decision. There's not an IBM software business, an IBM hardware business, an IBM services business, it's all one, interconnected.

JW: So is IBM being dragged by its little toe ... the next step is Linux, and the next step is you've got to put the 390 hardware diagrams on the Web ...

RW: Not at all. With Apache, we never set out to provide the best-of-breed web server for S/390. We had a web server, but I don't think we were trying to go head-to-head with other people providing that function. What we wanted to do was add value to the web serving environment by surrounding it with application enablers we call "Websphere". The web server is part of that, but it's okay that it's Apache. It made sense to go where the standards are going and be able to interoperate, to allow customers to use software from other companies that was written to the Apache standard.

JW: So you dipped your toes in the water with Apache, then GCC was needed for an internal project, and now you're contributing to the Linux source tree. You've given us the sense that it's still scary, but does it look like there's going to be deeper involvement in open source?

NF: They've already released JFS, Journaling File System, to the community. That's something that's really needed at the high end.

JW: Absolutely, that's really a great service to the community.

NF: The S/390 people have to talk about gigabytes and terabytes of data; can you imagine running 'fsck' on something like that?

RT: Linux on the S/390 is not some weird animal, it's Linux. It's not an EBCDIC system, it's ASCII. An S/390 is a computer, it's got a CPU, memory, disk, ethernet ...

JW: With this feature that you can run multiple systems on the same machine.

RT: Another feature is channelized I/O.

JW: Why is a mainframe different than, say, a big HP or Sun machine?

Why do banks and the IRS and so forth use them?

NF: The realization that business is about moving data, lots of data, quickly, securely and reliably, 99.99% uptime on these boxes.

RT: With Linux on top of VM, VM can handle this wonderful mainframe concept that you can have a processor go down and the system running doesn't feel it, you can bring another on line, and the system is still okay. Try that on a PC!

JW: And great I/O capabilities, in the realm where quantity becomes quality.

RW: The word is "awesome" I/O capabilities. Also, S/390 memory has parity checking. That makes it a little slower, but fundamentally error free. We detect and correct every single-bit error, and most double-bit and triple-bit errors. A VM system stays up for six months, routinely.

PS: You bring it down to add hardware.

RvdH: Though normally you can add hardware while the system is still running.

NF: There's no such thing as blue screen death on a VM system. It's a conscious decision to take it down.

DS: For over 25 years, we've been building this reliability, this availability, figure out what the operator meant instead of what the operator said. This is both hardware and the VM software. You cannot afford to be down. Windows and other systems have never felt the pressure to deliver that kind of availability. That continuous pressure cooker of deliver, deliver, deliver has put us ahead of the rest of the industry in those sort of reliability, availability, security, integrity issues.

JW: Linux itself is considerably less reliable than this! But what you're saying is that you can have a machine where there are 25 images of Linux running, each serving a few users, a few images can go down and other processes will bring them back up.

RT: And that you can have a hardware error, VM recovers the hardware error, and Linux never saw the error. Linux under VM is inherently more reliable than Linux on bare metal.

NF: Introducing the concept of VM to Linux users in Sweden, I called VM a "very intelligent BIOS". It does things intelligently between you and the hardware so Linux can get on with the job of serving Web pages and SAMBA and not worry about recovering CPUs and disk and memory checks and tape ...

JW: So some of the stuff that people might want to write into Linux doesn't have to be written if it's running on top of VM?

SR: VM is like the hardware abstraction layer.

RvdH: You also have the human factor contributing to mainframe reliability. If your application on the mainframe breaks, you don't just reboot the system, several people are sent out to debug the dump, you find out what caused the problem and get it fixed and make sure it doesn't happen again. That's an important aspect of the quality of the system.

PS: The MIS guys get called by PC users who have applications go down. The users get told, "Reboot," and they get angry and say, "MIS isn't doing its job." There's no way to fix some of these problems, because there's a fundamentally different mindset in the PC world.

You can get an ICE and get in there and figure it out, but you're not going to do it just because one day a year a word processor fails.

JW: What makes that kind of diligence economical in the mainframe world?

NF: Thousand of users on an application.

SR: And hundreds of applications running at once.

JW: At the peak of PC hubris, that was precisely the argument. "Let's escape from this kind of liability. Let's give everybody a computer, then if one goes down, just one goes down." What's the mainframe answer to that?

RW: The problem with that approach is that you then need a lot more people to administer. For every ten, twenty, fifty PCs you have, you need someone to look after them.

JW: But many DDJ readers do administer large networks of PCs and don't see this as being impossible.

RW: It's not impossible, but is it fun?

JW: Is administering mainframes more fun than administering PCs?

RT: Yes!

RW: One administrator can administer thousands of users. If you run VM, not only can one administrator administer thousands of users, but they can each have their own computer.

JW: So each user can be running their own Linux image?

RvdH: And the system would not have to be installed for each user.

The administrator provides one copy of, say, each of seven versions and a user can choose to IPL [initial program load] a particular version.

DS: And share one program library, so they don't have to be copied over and over again.

NF: And the disciplines of system management that have been part of the mainframe world for ages are applied, where you've got operators trained in disaster recovery procedures, and you have your backup sets taken offline. You can recover from the worst situations very quickly and securely. You just don't lose data that you can't afford to lose.

RT: And of course each user can configure his or her own virtual machine, override defaults configured by the system administrator. It is very much a sandbox. They can have their very own Linux environment.

JW: But you can still have multiple users logging on to one instance?

RW: You have that flexibility. Either way.

RvdH: Those users logging into that Linux machine will not notice the difference [between logging into VM and launching a Linux instance versus logging into to a shared instance via telnet] until they do a 'cat /proc/cpuinfo'.

JW: How are people going to evaluate how much Linux work they can get out of spare process space on their already-installed S/390? In the mainframe world you have all these scientists doing precise workload measurements, now all of a sudden you have this weird leak in your model, a multiuser system where one guy is running a Linux image for his own use, another with twenty-five users, another putting it out on the Web. Who is going to tell users what they can do with Linux in a practical sense on a given platform?

RT: This wonderful "intelligent BIOS" has all kind of knobs you can turn that have a real effect on how far the sandbox is going to stretch.

SR: And it also presents means to measure realistically.

RW: IBM is very interested in the answer to these questions. Resources are being committed to this.

RT: There are also some tools that need to come forward. There's a tool in VM called TRACK that lets watch what happens in a virtual machine. I'm looking forward to having more panels in TRACK that will allow you to pick apart more accurately a Linux virtual machine.

NF: I'm writing an experimental device driver that allows Linux to generate monitor data that the VM system can pick to do some metrics on internal stuff from the /proc file system. That data can be coalesced from a whole lot of virtual machines and we can accurately account not only for the Linux virtual machine, but also for the applications and processes running therein.

SR: There are two other things that come to mind about performance.

One is the issue of how VM can enhance the performance of the Linux guest. The other is the kind of horizontal scaling VM allows, where it can be appropriate to consider running individual applications in individual Linux virtual machines rather than bundling a number of applications in a single instance of Linux.

JW: There seem to be almost infinite possibilities. So IBM is going to help the customers sort out the optimal configurations?

RW: IBM is going to make some measurements and IBM is going to say something about them.

JW: In a redbook [an IBM-commissioned and co-authored treatise on a particular subject, http://www.redbooks.ibm.com]?

RW: There's going to be at least one redbook, and judging from the high interest of the customer community, more than one redbook.

NF: Rebooks are great, they are really right in the philosophy of open source, getting a group of people together to sit down and dedicate themselves to a task and publish all the results, publishing the code they used.

PS: You know that saying about, "Lead, follow, or get out of the way?" Ten years ago, IBM would have gotten out of the way. Five years ago, they would have followed. Now they're leading.

JW: So far, is IBM satisfied with the reaction of the customer and the open source world to their activities, or is it still controversial inside IBM?

RW: I think everything is controversial inside IBM! There is always more than one opinion. But it's fair to say that there have been several events that have produced interest and encouraged people inside IBM, not the least of which is [David Boyes at Dimension Enterprises managing to achieve] 41,000 virtual machines running Linux on one S/390. That certainly got attention in places where VM isn't necessarily mentioned very often. Also, the interest and enthusiasm shown by the VM community for Linux.

RT: This is something a lot of people have put personal time into.

There's a big passion behind this. People who understand the mainframe and understand Linux see the two coming together and get worked up.

This is cool. This is extremely cool!


Return to Linux/390 in the Spotlight at SHARE 94

About System 390

About System 390

The System 390, or S/390, comprises a broad family of mainframe computer models based on the 32-bit IBM 390 processor architecture formally defined in the 390 Principles of Operation manual (POP for short).

The 390 architecture is the lineal descendant of the 1960s IBM 360 and the 1970s IBM 370 processors. IBM 390 CPUs commonly run at 750 MHz. Forthcoming are both much faster CPUs and a 64-bit architecture.

A copiously illustrated view of the state of S/390 silicon is the recent IBM Research Journal issue "IBM S/390 Server G5/G6".

Multiprocessor machines commonly range from two to twelve CPUs. Processor and other S/390 hardware resources can be virtualized and partitioned between multiple operating system images in the "hypervisor", which runs at either the microcode level (Logical Partition or "LPAR") or at the operating system level (VM/ESA) [See sidebar, "About VM".]

Mainframes are much more than their central processing unit, being specialized for high rates of I/O transfer. Channel architecture offloads I/O operations onto discrete channel controllers which execute programs written into shared memory from the CPU, making byte data transfers inefficient but block transfers, especially large block transfers, more efficient than with the sorts of I/O architectures common in the PC and Unix world.

Mainframes are also valued for their reliability, as Byte pointed out in a 1998 article, "Why Mainframes Rarely Crash."

S/390 mainframes run a variety of operating systems either natively, in an LPAR, or under VM. These operating systems include VM/ESA, OS/390, DOS/VSE, TPF, and now Linux.

Qualified application developers (see the S/390 PartnerWorld for Developers web page) can obtain S/390 hardware at a discount, and the VM operating system without monthly licensing. IBM sales philosophy being very much based on one-on-one relationships with individual customers and developers, general price information is as hard to come by as free advice from a lawyer; however, it appears that the entrée for an up-to-date developer model is around $15,000, substantially more than a Unix workstation but also substantially less than $500,000 to $2,000,000 a commercial user might easily spend for a production S/390 model.

Alternatives to owning your own IBM S/390 include the following:

  • Emulation on Intel, available from Fundamental Software Inc.,
  • A local university, many of which can provide accounts on an S/390,
  • Contract programming at IBM, which will often bring the contractor into formal or informal contact with the S/390
.


Return to Linux on the IBM S/390

About IBM's Corporate Evolution

About IBM's Corporate Evolution

IBM was incorporated in 1911 as the Computer-Tabulating-Recording Company, as a merger of Computing Scale Co. of America and International Time Recording Co. with Tabulating Machine Co. founded in 1896 by German immigrant Herman Hollerith. Thomas J. Watson, Sr. joined the company in 1914 and became president a few years later. IBM's capsule history is available online for more detail.

IBM in the 1950s reluctantly entered the electronic digital computer age. Rapidly, IBM became both the dominant player in the nascent industry and an international icon of the corporate mentality typified by their motto of "THINK" and by the blue-suited, business-first attitude of their representatives. Also an icon of his time was the stubborn and laconic Thomas J. Watson, Jr, CEO of IBM from 1956 to 1971.

In the 1960s, the IBM 360 processor architecture was introduced, which has remained the flagship of mainframe computing to this day, evolving through the System 370 and System 390 architecture. To the average office worker, however, IBM was better known during this period for the Selectric typewriter.

In the 1970s, IBM encountered antitrust problems with the U.S. Justice Department, at first over the company's contention that competitor's software could be excluded by license from executing on IBM platforms, and later simply over the ability of IBM to stifle competition by its size (IBM had also inspired antitrust action in the 1930s and 1950s.) The result was a series of judgments and a consent decree voided only in the 1990s.

In the 1980s, retrenchment, complacency, and cronyism drove the company economically downhill, paradoxically during the period when it had perhaps its most profound effect on computing by delivering the IBM PC. As the decade closed, it became apparent that IBM had lost the lead in personal computing in light of market rejection of their closed PS/2 hardware architecture (successor to the very-open PC, open down to the full listing of the BIOS assembly code in the manual) and in their hang-fire operating system initiative, OS/2. Mike Cowlishaw's Dictionary of IBM Jargon at that time defined "visionary" as "an IBMer who reads outside literature."

Stockholder rebellion in the 1990s put current CEO Lou Gerstner in charge, the first outsider to hold that post. A series of first-ever layoffs shook IBM morale for a time, but the company has rebounded strongly with initiatives in electronic commerce, web serving of enterprise data, Java, and other Internet tools, leading to the not-entirely inaccurate programming community perception of this century-old institution as pretty hot among the cool companies of our time. An emerging focus at IBM is the compute-everywhere metaphor.

IBM is putting resources behind open source software, and on the Open Source Zone, it maintains a list of packages officially grouped under the open source metaphor. Remember that IBM is the biggest computer software and hardware company on the planet and has many mansions, so to speak. Elsewhere in IBM you will find open source software written by IBMers and/or customers that doesn't appear on that page.


Return to Linux on the IBM S/390

About Linux/390

About Linux/390

The path to Linux/390 took many twists. An independent group of VM programmers were working on a GCC and Linux port to S/370, the architectural antecedent of the S/390. Meanwhile, behind the scenes, IBMers at Boeblingen, Germany were working on a 390-only port.

While Linux can run as the native operating system of an S/390 mainframe, it also runs in a logical partition [LPAR] or under the VM operating system. Linux running under IBM's VM/ESA virtual machine operating system presents unique opportunities for synergy, since VM's virtualization of every aspect of the machine, from the processor instruction set to L3 caching and disk caching, obviates the need for certain kinds of performance enhancements that Linux kernel hackers would have to author independently for particular hardware platforms. Linux on top of VM can, to a large extent "just relax and go with the flow" in matters such as virtual memory paging and multiple processor support.

Other Resources


Return to Linux on the IBM S/390

About Open Edition

About Open Edition

Unix on IBM mainframes is not new. In the 1980s IBM's AIX/370 ran but failed to maintain sufficient customer enthusiasm: AIX was different enough from popular Unix implementations to require substantial application porting effort.

In the 1990s, Open Edition emerged on VM CMS and on OS/390 (Open Edition is generally referred to as USS, Unix System Services, on the latter platform). A shell runs POSIX-compliant applications on either system, with access to host operating systems services.

Open Edition has been a successful draw on OS/390, with popular ports including Apache web server. However, on VM, the emulation of POSIX has been somewhat less well received, for reasons ranging from interoperability problems between shell applications and CMS applications to imperfect emulation of POSIX calls such as fork().

Nonetheless, VM enthusiast Neale Ferguson has managed to port several major open source packages to VM Open Edition.

Linux/390 appears to be the most persuasive Unix offering ever to emerge on the S/390 platform.


Return to Linux on the IBM S/390

About SHARE

About SHARE

The sign at SHARE 94 (no, not 1994; rather, the 94th meeting) said, "SHARE isn't an acronym; it's what we do!" SHARE was founded in 1955 by customers of IBM to enhance the members' education and interpersonal communication regarding information technology. The first meeting was largely composed of users of the IBM 704. Today, the organization boasts many thousands of members and a peer network of over 2,000 member companies who represent Fortune 100 companies and educational institutions.

SHARE 95 will take place at Boston's Hynes Convention Center on July 23-28, 2000.


Return to Linux on the IBM S/390

About VM

About VM

The Virtual Machine operating system, VM, began as one of those simple yet powerful ideas. VM virtualizes the entire S/390 mainframe so that a virtual machine running under VM can run any S/390 operating system, which then "thinks" that it has an entire mainframe at its disposal. Thus, VM can launch a virtual machine instance of VM, which can itself launch a virtual machine instance of VM, as in "recursion, noun: see recursion." All hardware facilities are virtualized by VM, leading to an architecturally assisted, seamless self-emulation that is a model of completeness and efficiency.

VM is used in production to run multiple operating system instances simultaneously on one physical mainframe, to test and debug upgraded systems side-by-side with production systems before deploying the upgrade, and by IBM to develop and debug VM and other S/390 operating systems such as the flagship OS/390. No virtual machine can crash another virtual machine; the isolation of each emulation is hardware-supported and solid to a greater extent than the isolation of processes under Unix.

VM was developed surreptitiously in the mid-1960s on the IBM 360. Upper management were told a half-truth, that a "debugger" was being coded to help debug a flawed and failing management-approved 360 operating system, which shortly thereafter sank without a trace. Accounts were juggled to conceal the labor being poured into a compelling technological hack that consumed the creative fire of scores of dedicated engineers and their nimble managers who provided cover for the project.

Once the secret was out, the product was released. Enthusiastic customer acceptance led to changes in the planned 370 architecture to lend hardware support to the virtualization principle, which the 390 architecture took even further in the 1980s.

VM has two main components: CP, the control program, which is the heart of the virtual machine model, and which resembles, from the point of view of any virtual machine it launches, a constantly accessible ROM monitor; and CMS, a flat-memory single-user operating system which is the most common virtual machine launched for native VM development.

Over the years, VM has had a great, if largely unacknowledged, impact on personal computing. The concept of a personal computer itself originated among VM users who had, in effect, just such a beast in each CMS virtual machine. Intel 80386 V86 mode, which provides hardware support for 16-on-32-bit virtualization, is a knockdown of the 370 support for VM. In recent years, interest has grown in virtualizing 32-on-32 on the Intel hardware, leading to commercial products such as VMWare and its open source shadow, Freemware, both of which can run simultaneous multiple operating systems on a single PC in a fashion analogous to VM's virtualization of the S/390. (Though the Pentium lacks the mature hardware support for virtualization present on the 390 architecture.)

VM is known wryly around IBM as "the operating system that outlived many of the managers who tried to kill it." For a technologically fascinating and dilbertesquely humorous summary of how VM emerged in response to IBM engineers' and customers' needs despite an IBM managerial mental block, read Melinda Varian's VM and the VM Community: Past, Present, and Future.


Return to Linux on the IBM S/390

Terms of Service | Privacy Statement | Copyright © 2024 UBM Tech, All rights reserved.