I remember when LAN Mania spread like influenza in the 1980's, something didn't seem quite right. Oh, sure, it made perfect sense to move data faster around the office. It's just that the selling point was to solve the problem of people carrying diskettes to the PC that had the printer. Remember that? Oh, yes, and to allow people to share files (I just don't remember needing to share a lot of files with other people, myself). And that's exactly how a lot of the early LAN stuff was sold — by computer-newbie salespeople to non-technical business owners and managers, to replace "sneakernet."
LANs proliferated and Novell became the big kid on the new block. Users were finally "empowered," and a revolution was in the making. The revolutionaries set their sights on bringing down the Goliath of the big computer in the glass room. Mainframes and minis were going to become extinct, and the sooner the better.
The basic idea was not to reduce computing activity, but in a symbolic sense to dismember the mainframe and drop a chunk on every desk, wiring them together with ethernet. What was wrong with that picture?
Well, in principal it's a lot more difficult to make something work fast and well when its parts are distributed over a couple of acres. The links between the parts are relatively slow and fragile. A malfunctioning part can prevent other parts from communicating. People kicking wires loose under their desks suddenly becomes a system reliability issue. Then, too, when human beings are operating and fiddling with each of the parts of the distributed whole, there are bound to be lots of surprises and lots of variables.
Daisy-chaining all the PCs, one of the original selling points, didn't work out very well, either, and in time we were back to individual cables to each PC. To be sure, twisted pair was cheaper than mainframe coax, but by that time the proprietary workstations were able to use twisted pair, too. Besides, most of the mainframe connections were already in place. Did it actually save money to pull them all out and replace them?
Novell meanwhile found itself reinventing most of the OS technology that was already taken for granted in large machines. Shared access to files, for instance, required flawless coordination between clients and servers. I seem to recall that the LAN server industry grappled with gnarly problems of record locking for the longest time.
Then there was the client/server fad. Some people are still caught up in it. Originally, it was going to solve the problem of those turtle-slow, MIS departments and their monolithic applications. All we had to do was drop a server program in that fast-growing server box (may we have some more memory and another disk or two, please?), drop a client program in this desktop PC (oops! a little more memory and disk here, too, if you don't mind!), and a new application would be up and running . Sort of. There were two really big problems with that.
Early on, client/server apps were almost always large, in-house projects for the simple reason that there was little client/server software in the marketplace. No one seemed to notice that this replacement for monolithic MIS projects for mainframes was an approach that required a much larger effort – that of building and maintaining a multi-platform divided application with a far more complex user interface. Many in-house client/server projects suffered from all the ills of the former in-house mainframe projects, with the complications of multiple platforms and languages, and a non-trivial network linking the parts.
More recently, client/server packages of seemingly acceptable robustness are increasingly licensed from third party vendors. In many cases, though, it has been (and continues to be) an often painful, rarely pleasant learning experience. The customer pays for the education of the client/server vendor while suffering through a long series of silly problems that would never have been tolerated from the old MIS department. Like as not, by the time the problems are settling down, a newer product will have been selected by upper management and the whole process begins again.
That was about the time when almost every organization sprouted a significant "help desk" operation. Users who previously had to do nothing more than turn on the terminal and log in now had to deal with a virtually limitless scope of configuration and operational issues. Issues similar in nature, if not in scope, to running their own miniature mainframes, which is really what it had come down to.
Characteristic of all of this is what I think of as the Great Technology Break. The entire PC revolution, in all its aspects, made a significant break with prior technology simply by ignoring it. The engineers and the budding programmers of the early microcomputers grew out of the corners of electronic engineering where 4-bit microchips first found their application. As the 8-bit and 16-bit chips came along, this new field bred its own software developers who, for one reason or another, treated micros as a completely new field. They reinvented much of computer hardware and software engineering without regard to anything that had previously existed.
We eventually got the GUI that had existed at Xerox before the whole revolution started, but the people who brought it to us insisted on doing everything from scratch. They reinvented disk directories, assemblers and compilers, object libraries and linkers, debugging tools, rudimentary operating systems, file systems, shared file access, file and record locking, transaction processing and rollback, communication protocols and, finally, something remarkably like multiuser operating systems with "pre-emptive multitasking" -- in short, all the things that had pretty much existed in the large computer world before the micro revolution had begun, plus some things that were perfected in the large computer world while the micros were still struggling with them.
One example is the LAN protocols. Now that the inadequacies of SPX/IPX are inescapable, LAN/WANs are migrating to TCP/IP. One might assume TCP/IP is a newer development, but it isn't. It was developed in the mid-1970's and displaced all other protocols in ARPANET in 1983, about the time that PCs were making their appearance. TCP/IP was scalable and is now serving millions of host computers and between 50 and 100 million users in the Internet.
Thus we all paid for the on the job training of this new industry. We paid in money, lost time with program crashes, often-flawed software and all-night sessions with configuration nightmares. Perhaps most costly of all, we paid in the calendar time spent waiting for this new industry to just catch up to where the bad old large computer industry had been. It took about twenty years, all told. Fifteen, if you don't count the early beginnings before widely available PCs.
Now we have a total cost of PC ownership that is coming to look something like $5,000-10,000 per year. Per desktop. That's two to three times more than the corresponding cost of bringing modern large computer services to the desktop. The difference should be even greater when the large system is already paid for.
Now we have servers, those things that started out as cute little PCs back when the early LANs were installed, ranging all the way up to $750,000 superservers. The larger ones have to be located – you guessed it! – in the glass room, with UPS, A/C, the works. The smaller ones have to be in there, too, unless you want ugly failures every time the power dips (or someone kicks a power cord loose).
That's a long road to have traveled from the promises of saving money by cheaply interconnecting PCs and by getting rid of the mainframes, only to arrive at the end to find glass rooms with million-dollar computers, very costly networks, and expensive, unmanageable PCs on the desktops. Untold billions of dollars and the better part of twenty years have been spent in reinventing… well, mainframes, I guess.
At this point I'm probably overdue in pointing out that I'm not a dinosaur. Networks were inevitable. More capability directly under the control of users was inevitable. Better, nicer, prettier user interfaces were inevitable. I don't argue against any of the positive results the micro revolution has produced – I'm just not really pleased with the exceptionally messy and mindless way that much of it came about, and the destructive effect it has had on well-developed non-PC, non-unix software technology.
The traditional computer industry has to shoulder a lot of the blame. It was they who disdained the new technology and left it in the hands of microwave oven engineers to develop. It was they who ignored PCs and provided little more than perfunctory terminal emulation as a sop to insistent users. It was they who failed to detect a paradigm shift in progress – a "sea change."
Business management has its share of blame, too. In the era before the revolution it was still thought necessary for managers to understand what they managed. Concurrent with the change in technology has come a change in business philosophy such that today's management is expected to understand only management and, too often, micromanagement. Thus we have executives selecting major software packages for the organization without any input from anyone knowledgeable in software. Thus we have executives deciding to phase out the large computer in favor of trendy client/server without even knowing the hundreds, even thousands of functions that run on the large machine or what will be the cost of their replacement.
Still, though, there are organizations where the reality of major existing investment in large, mature, stable applications dictates that the big machines be given their due. Vendors for their part have been packaging more mainframe power in smaller boxes for less money, and have added TCP/IP and a host of other up-to-date features to keep their machines functional in the evolving computer and networking landscape. Even as the once-small network servers approach the cost and complexity of traditional mainframes, the new mainframes have stabilized in a market position that is unlikely to be threatened anytime soon. They don't, after all, perform the same functions in the same environments, and are not close to becoming interchangeable.
Further, the body of programs running on larger machines has been estimated to be so massive that it would require all the programmers in industry working exclusively on conversion for the next several decades to convert it. Whatever the size of the feared Year 2000 problem, any thought of completely converting the same programs to another platform is by definition many times greater in magnitude.
Which brings me to my point: After a long and painful excursion through a fantasy land that promised cheap and easy computing entirely in the hands of users, we see that road coming full circle to a world of very large, centralized systems. Servers have arrived at many of the robust features for which mainframes are known. Mainframes have evolved to be smaller, cheaper and more powerful, with new features taken from the best of the micro revolution. Both are becoming equally accessible from the desktop, and soon it will be difficult or impossible to distinguish which is serving the desktop user at any given moment.
The promised land of idyllic cooperative desktop computing has turned out to be one of a proliferation of servers, some of them in the million dollar class, expensive desktops loaded with costly software, and an administrative nightmare. Oddly, the one-way ticket to this world is often a Wang VS system thought to be less than cost effective only because no one has bothered to upgrade it in ten or more years.
Now is the time to take a second look at the VS that may be targeted for phase-out. Upgraded to current processor and peripherals, it may well be an asset worth keeping in production.
—————
Thomas Junker is a VS software developer and consultant in Houston, Texas. He may be reached by email at
. His well- known Unofficial VS Information Center website may be found at www.tjunker.com/.