SHARE -- Alan Altmark - Mr. z/VM
Alan Altmark, an IBM Senior Software Engineer, is Mr. z/VM to the developer community at large. He's a developer who coded and evangelized his way up the organization to ombudsman. He's cheerful, bright, and frank and he is ubiquitous on developer fora and mailing lists. If Alan can't figure out the answer, there isn't one.
JW: How do I express to my readers how much fun it actually is to program z/VM?
AA: Our ability to create our own virtual machines via the hypervisor without having to go through red tape is very dynamic and quick to test.
JW: What is the programmer aesthetic of paying this great investment in time to learn this venerable architecture to get these virtual machines?
AA: Since all programming has a goal, we take great satisfaction in designing and developing new functions, new ways of thinking about virtualization. Even though they are based in 40-year-old technology, the concepts are as fresh today as they were then, and as useful.
JW: Your bio indicates you had serious coding responsibilities, which anyone who interacts with you on the net would guess. Do you do much coding now? Any?
AA: I do some coding from time to time, but my primary resonsibilities are in architecture and design, with focus in the security arena. That includes authentication, authorization, certifications, and audit facilities, as well as threat assessments.
JW: When you say security nowadays that means, effectively, TCP/IP security?
AA: TCP/IP is one aspect of the security I concern myself with. But I also have to worry about what happens when a remote program finally reaches VM, what can it do and not do? What if there's a failure in the guest operating system?
We have three primary goals for security on z/VM called the Statement of Integrity. The first is to insure that the Control Program, CP, can operate without interference or harm from a virtual machine. Second, we insure that virtual machines can not get around any security measures the control program establishes. Finally, with those two things in place, we insure that virtual machines can't interfere with each other.
In that context, TCP/IP is just the pathway into the wide world of a virtualized environment.
JW: Do you get to talk to young programmers much about z/VM?
AA: I occasionally have contact with young programmers. Maybe I'm speaking to a customer and they have young programmers; or on our own team, the z/VM Development team.
JW: Are there going to be people to appreciate and code at all levels this wonderful architecture in five to ten years? Or will it somehow all be hidden under these environmental bridges that people are writing that attempt to turn z/VM administration into a web application?
AA: I think that people who adminster a system still must understand what they are trying to administer or they will fail. You can change the interface and make it simpler but you can't remove the requirement for knowledge and intelligence.
JW: Is "real" z/VM programming still what it was when I was doing a tiny bit of it, largely assembler, REXX and C/C++?
AA: That's the primary environment.
JW: What's the weighting of that now? Does assembler still dominate or is new work being done in C/C++?
AA: For the hypervisor , assembler dominates. There is some C in the control program, but its mostly assembler.
JW: What's done in C in the control program?
AA: Device drivers ported from other platforms.
JW: Among the z/VM C programming arcana I remember was the Language Environment (LE) . Is that still there?
AA: LE is still there, but you can write POSIX programs in this environment.
JW: And all you have to remember that isn't regular C/C++ is the linking fu that goes with LE? Or are there other ways LE obtrudes in C/C++ programming on z/VM?
AA: It's nothing special. It's just linking.
JW: What's the language choice driver in z/VM development?
AA: Our developers are fully immersed in the architecture of System Z which will drive the use of assembler because it directly reflects the architecture.
JW: Which is an approach, like so many others, e.g., stream vs record, in which mainframe praxis diverges from the stated goals of so much else of the software development community. What is the software engineering or computer science point we can draw from this approach being so viable even today after decades of general development praxis largely fleeing from that approach?
AA: Software reuse. Years of legacy assembler exists in the system. It is easier to integrate assembler into that environment than to bring C programming in.
JW: So does this support making assembler easier or at least more powerful and workable in the mainframe world than it is, perhaps, on the workstation?
AA: Because we in z/VM development are in the operating system development business and not the application development business, that enables us to have this luxury, if you will, of programming in assember. The most efficient control programs will be those that take advantage of the hardware platform, full advantage, rather than using lowest common denominator solutions.
JW: What first impressed me about VM was when I discovered the macro libraries, which contained the most mature software I had ever encountered in my career.
AA: Macro libraries represent the collected "wisdom of the ages".
JW: How do you maintain them at the necessary quality level? What's the methodology for protecting them against all inadvertent harm, as perfect as they are?
AA: IBM has established well-defined product developent processes that include rigorous code control and review processes. Wiser heads will be in the room when changes are discussed. That wisdom is passed down with each programming generation.
JW: So there is a consciousness in the z/VM Development team that this is not just an exercise, this is a human effort, one that is transgenerational?
AA: Indeed. We think of ourselves as a family. We include our customers as a part of that family. We take great care to make sure our customers are taken care of not just now, but also into the future.
AA: It does. I've been in z/VM for nearly 30 years. I've been working with many of the same people that entire time.
JW: Are you hanging in there? In the words of the Rolling Stones, is your brain still flashing?
AA: It is. Working with the mainframe does not mean working in a cave. Our systems still are presented with the challenges all systems are presented with: to be efficient, to be functionally robust, to be secure, and to meet the client's needs. In my area of security, the bad guys are always looking for a way in. It's my challenge to keep them out. When the value of the target is high enough, it being a mainframe will not be a limiting factor, the "strangeness" of a mainframe is no protection.
AA: Yes, I am aware of these and impressed, but not surprised, that there are individuals all over the world working to make open systems more secure. It's a fact of life. If people want open systems to be ubitquitous, security is a must-have feature.
JW: Have open source security efforts directly influenced and benifitted z/VM development?
AA: To the extent that the way people interact with security subsystems in open systems has helped to define how you interact with those subsystems on the mainframe. We look for ways to make them more common so that concepts are transferable even if the syntax is different.
JW: Is some, for example, of OpenSSL in z/VM?
AA: There is no open source code in the z/VM security subsystems. Some applications shipped with z/VM which reside way above the hypervisor and basic services contain some BSD code.
JW: You hacked it out yourselves line by line.
AA: Yes. What might not be obvious is that these security subsystems were being developed before there was such a term of art as "open source".
JW: But there must have been a deep continental rift when TCP/IP become dominant, and that has only happened in the past 15 years.
AA: The primary security mjeachanisms in z/VM are well below the layers of TCP/IP as they were also well below the layers of SNA.
JW: We're not talking about RACF here, we're talking about something more fundamental?
AA: We are talking about the Control Program's basic enforcement of those three principles I enunciated earlier, the z/VM Statement of System Integrity. For example, with SSL, SSL protects an application, whether it's FTP or TN3270 or whatever. At the end of that communications pipe is a virtual machine. Our security principles in the Control Program are meant to protect the virtual machines without regard to the applications they are running.
JW: How does a programmer go about getting some z/VM exposure today? There seem to be fewer mainframes on campus than 30 years ago.
AA: IBM has established an academic initiative to bring more mainframe capabilities to colleges and universities around the world so that students can get experience with System z . We recognize that the design leaders of tomorrow are the students of today.
JW: Is mainframe programming really any different than any other kind of user-interactive computer programming?
AA: Mainframes are not alien life forms. They are computers with CPU, memory, I/O devices, with an architecture that marches to the beat of a different drummer, but requires the same intelligence, drive to succeed, and work ethic as on any other platform.
Our work in z/VM development is about operating system development. That' s a different task from application development. Requires a different set of programming skills. There is a language difference, one easily overcome.
People who write Linux applications will find the same tools in Linux on System z as they do with Linux on any other platform.