By Jay Maynard
Once upon a time, IBM systems were what people thought of when they thought of "computer". IBM's market dominance assured that it stayed that way. A big part of this was that college students working on computer courses - especially those at the larger, more advanced institutions - ran their programs on IBM systems, and got to know IBM OSes and languages. Those who were interested enough in playing around with the systems to learn more did so within the IBM framework. When they entered the workforce, they were prepared with skills employers demanded - as long as they had IBM systems, that is - and so this helped the snowball grow bigger.
The college effect is widely credited with the current dominance of the Unix platform. In the 80s, colleges went to the Unix platform in droves, both due to the availability of source code (in comparison to IBM, where object-code-only policies, among other things, destroyed the utility of the OS as a teaching tool) and the less expensive nature of the hardware needed to run Unix. Students left school thinking of Unix as the be-all and end-all of OS design, and when it came time for them to make decisions in the workplace about what to use, they went with what they were familiar with.
This is especially apparent with the evolution and meteoric rise of the Linux operating system. Linus Torvalds set out to learn how the 386's task management system worked, but needed a conceptual framework to do so - so he picked Unix. The rest, as they say, is history.
This illustrates the problem: in one word, it's mindshare. Nobody thinks of IBM mainframe systems when they think of modern computers. When they do think of IBM mainframes at all, it's "that oversized, powerhungry dinosaur in the locked room that we haven't gotten rid of yet in favor of something modern". This is true even of computer professionals in enterprises that depend on IBM mainframes for their day-to-day operations. They point out Linux and Solaris as shining examples of reliability in computing, and don't even think about the fact they're learning lessons the hard way that mainframers have known about for the last 30 years - and, in the process, adopting the same kinds of restrictions and procedures that, once upon a time, they thought were senseless and a pain to deal with.
Coupled with this is an increasing shortage of qualified systems programmers. While the market for those skills shrinks, the availability of those skills shrinks faster, as systems programmers see the handwriting on the wall and switch careers to ones they see as having better prospects for long-term employment. The result is that the average salary for systems programmers is constantly increasing, as is the average age of the systems programmer, and the same trends are evident in the applications programming and operations fields.
IBM has made a real splash in the Linux world with the introduction of Linux for the S/390 and z/Series. Companies are deploying Linux on their systems at an accelerating rate, and at least one large ISP has installed a 390 specifically to run many instances of Linux on. Unfortunately for the widespread adoption of Linux on the mainframe, though, the only practical way to do this is in conjunction with z/VM, and that requires systems programming expertise.
Compounding this fact is that there used to be no practical way for someone to play with a mainframe and gain practical, hands-on experience. There are plenty of books out there on IBM systems programming, but nobody's going to turn over an entire mainframe - or even an LPAR on one - to someone to play around with. It's simply far too expensive. Even the P/390 was, until very recently, out of the range of the hobbyist.
Computer geeks, above all, like doing things with computers. If they want to learn about something, they get their hands on one and play with it until they've accomplished whatever they set out to do. If they can't, they'll find something else to poke at.
In the past two years, the picture has changed. The Hercules S/370, ESA/390, and z/Architecture emulator [ http://www.conmicro.cx/hercules ] has come along to the point that it is a full-featured, capable platform to run IBM OSes on. Users have reported running everything from OS/360 through z/OS and z/VM successfully, and all on their Linux and Windows PCs. On a suitably fast PC, the system runs quickly enough to provide subsecond TSO response time, the holy grail of OS/390 performance tuning.
For the first time, it's feasible for a computer geek to run his very own mainframe. While I know of one person who has his very own 4381 in his house, complete with DASD and terminals and tape, he's very much the exception. (I hope I never have to help him get the CPU out of his basement!) Now, however, the interested person can do his experimenting on hardware that's practical to own and operate and that doesn't even have to be dedicated to that purpose.
The remaining obstacle to the hobbyist is the OS. Some OSes, such as OS/360, were never copyrighted by IBM, and so they're freely available and distributable. Unfortunately, they're old enough that nobody's running them for real any more. For the last 20 years, all IBM OSes have been copyrighted program products for which real money was charged, and at a level that only a medium to large business could afford it. I'm not going to get into the argument over IBM software pricing, but I will note here that the least expensive one-time license fee for z/OS today is within a steak dinner of $40,000, and z/VM and VSE/ESA are both in the five-figure range. This is well beyond the reach of the hobbyist.
While the hardware itself was impractical for hobbyist use, this didn't make much difference. Now that anyone can run a mainframe in their living room, it's a major obstacle.
Another company has been down this road before. DEC had its own successful line of large minicomputers, the VAX series, and an OS that went along with it, VMS. For years, VAX systems were impractical for the hobbyist. Unix came to the VAX platform early, and became the experimenter's platform of choice on that hardware due to its widespread use in the university environment. As systems got smaller and then obsolete for production work, they started trickling into the hobbyist market, where the OS of choice was still Unix - because there was no other option.
In 1996, Pat Jankowiak made a presentation to DEC at a meeting of DECUS, the DEC user's group. He brought up many of these same points in his presentation, and argued for a hobbyist license for OpenVMS. DEC agreed, and set up a program. It worked well enough that the program was expanded to cover all versions of the OS, as well as both the VAX and Alpha platforms, and is still going successfully today. Because of this program, many people have been able to experience VMS firsthand and gain an appreciation for its true capabilities.
I propose a hobbyist license program similar to the one administered by DECUS for VMS [ http://www.montagar.com/hobbyist ]. A user would register with a central agency, and would in return gain the right to legally run the software for a period of time strictly for non-commercial purposes.
The exact details of what the license would cover are left intentionally vague. There are several options. The most desirable, I believe, is for the license to cover all software on the Application Developer's CD for the currently available version of the OSes. This packaging of IBM software is already being developed and integrated for other purposes by IBM, and would provide the most functionality to allow the hobbyist to become familiar with the true capabilities of the system. Another option is to allow the use of a previous version. This was what DEC originally did, and would minimize the risk that the system would be abused for commercial purposes - but it also lowers the utility of having a pool of prospective systems programmers training themselves. Still another option is to license those program products which only run on pre-ESA 370 systems, such as MVS/SP version 1. This has the same disadvantages and advantages as the previous option, only more so; it does, however, exclusively involve only those programs from which IBM gets no serious revenue today.
The agency to run the program is also an open question. DECUS does so for the VMS license, and SHARE would seem to be the logical choice for this program. There's one difference, however: DECUS allows individual memberships at no cost, unlike SHARE. The $250 SHARE membership fee would be a significant barrier to entry here. There's no reason that the participants in this program would have to be members of the administering agency, however.
A final detail is how the participant would obtain the software desired. This depends to some extent on what is licensed; if the ADCD is licensed, then the user would simply obtain one, while if an older OS and programs is licensed, a copy would have to be obtained somewhere and a distributable package built. This is not as big a hurdle as it sounds, as it's already being done for MVS 3.8. In any case, who actually distributes the software, as well as the cost involved and other details of administration of the program, can be worked out.
I propose that hobbyist licensees not be given any access to IBM support beyond access to the searchable PTF database online. This is only of value if current products are licensed; if the license applies to unsupported versions, even this is unnecessary. This removes a significant cost to IBM, and the hobbyist does not expect to get formal support for something which he hasn't paid to get. This is consistent, for example, with the well-known Linux distributions, all of which only offer support for those who purchased the software from them.
In a word: mindshare. The computer hobbyist who has been curious about IBM systems can experience them for himself, at very low cost and in the comfort of his preferred computing environment. He can gain experience needed to give him entry into the world of IBM systems or applications programming, if that's his desire. The Linux expert can gain experience with using it in a real-world mainframe environment. Most importantly, the mainframe can be seen not as the dinosaur that it's currently thought of, but as the serious contender it truly is.
Last updated 13 February 2002
Copyright 2002