My Prescription for the Wang VS
My Prescription for the Wang VSMay 17, 2005 - The joint press release announcing the Jan 18 signing of the agreement between Getronics and TransVirtual Systems made it out today. You may view it here:
or here:
Updated 28 Nov 98
Notes added 17 Jul 05, updated 05 Nov 05
More added 27 Apr 07
Note: This is a new page and is still in need of quite a bit of editing. I've pulled together some things from my email archives and other notes and writings, and want to air the concepts first and polish later.
20 Sep 98 - New or revised in this update (changes in boldface):
Full Table of Contents:
Without consultation with anyone at Wang, with no knowledge of what Wang may be planning (or not) or may actually do (or not) about any of these issues, and with apologies in advance to those with sensitive feelings or rigidly fixed ideas about these things, here is part of what I would like to see Wang do with the VS:
27 Apr 07: We tried to acquire the VS business FOUR TIMES in the first half of 2004. Various proposals have been made and discussions held since then, but we are not holding our breath. What will happen will happen, or not. Meanwhile, smart VS customers are moving to the New VS and enjoying its benefits with no separate conversion risk or cost whatsoever.
A novel concept, eh? While it's clear to me that the maintenance revenue from the installed base of VS hardware is the only thing that enabled Wang to emerge from bankruptcy and strike off in new, non-hardware directions, it is anything but clear that it makes good business sense for VS Engineering to remain a captive stepchild of the new, reinvented Wang.
Any entrepreneur would leap at the chance to take a business that generates several hundred million dollars a year, with a large installed base of high-quality products, and breathe new life into it to make it a vibrant, viable enterprise capable of growing into the future.
This kind of move began to make sense as Wang went in new directions after emerging from bankruptcy. As the new directions became entirely disjoint with the VS business, it struck me that the new business should have taken a new name for itself and left the old name to the VS business. After all, several million people have personally used Wang computers, and many tens of thousands, perhaps even a hundred thousand or more, have managed VS systems. Add to those all the others for whom Wang Laboratories is a name that means computer systems and you have a very large name-recognition demographic.
When Wang Laboratories changed its name this year to Wang Global, it not only freed the traditional name for use (other Wang-approved use, of course), it made it crystal clear that the VS product group is now laboring under a name that confuses and confounds. None of the equipment in the field bears the name Wang Global, nor do the software, manuals, screens, or machine readable documentation, some of which go back many years.
Now is the perfect time to set all that right, both in name and in business structure. I'm not optimistic, though, because it seems that the people of the "new" Wang may not fully realize how little of their business is of interest to the people who make up the several-hundred-million-dollar VS marketplace. Time and time again various "new" Wang people have told customers how they were going to help them migrate from the VS, how they were doing wonderful new things in non-VS areas, and time after time the old line VS customers have pounded the table and shouted, "When are you going to get it? We like the VS! We don't want to hear about what else you're doing -- we only want to hear what you're doing to support and advance the VS!"
I believe that the future of the VS depends in large part on the vision and planning of the leadership that controls the pursestrings. The only way for that leadership to keep its eye on the VS is to spin the VS division off so it has its own leadership, undistracted by all the other new things Wang Global is getting into.
27 Apr 07: This is pretty much irrelevant now.
Odd as it may seem to customers, the VS CE's do not work for the VS management. The customer engineering / field service management hierarchy has no connection with the part of Wang responsible for VS product engineering and support, at least not until one follows the chain of command up to the stratosphere of corporate management. It's part of a completely separate organization whose present thrust encompasses a much larger scope than mere VS maintenance. Both responsibilities should be under management of a spun-off Wang Laboratories, Inc., a company devoted entirely to the VS and whatever may spring from that work.
Bundle nearly everything
Way back when, everybody unbundled their software because IBM unbundled theirs. The only thing was, IBM didn't do that because it was necessarily a good idea, they did it because they were forced to unbundle by an anti-trust action. Now, IBM is back into bundling, and AS/400 managers love it. A friend of mine is one (an ops manager, not an AS/400), and bundling is at the very top of his list of reasons why he likes the AS/400. He doesn't have to write software, so he doesn't care that RPG is a Stone Age language. What he likes is that once the machine is there, licensed and under maintenance, he can get almost anything in IBM's software inventory just by picking up the phone.
In my opinion Wang, like many other modern corporate organizations, is probably afflicted with the Invasion of the Bean Counters. Those are the type of people who used to wear green plastic eyeshades and who "kept the books" in back rooms that visitors couldn't find even with a map. In recent decades they've bootstrapped and lobbied their way into upper management in many companies, and their favorite question when someone is looking to fund a project is, "How will we recover the cost of this project?" That's where the obsessive-compulsive unbundling comes from.
Now that's a reasonable question if you're trying to field a new model of computer, but it's an unrealistic question when you're trying to maintain the software infrastructure of the system -- the stuff that keeps the platform viable and competitive so the company can hold onto its market and its maintenance revenues. The idea that every single project on which the company might spend money must pay for itself on its own terms by bringing in its own revenue is, well, ludicrous. Sure, in the end, everything has to be paid for from revenue. But some costs have to be planned to be built into the product or service price structure because the market will not well tolerate being nickel-and-dimed to death with charges for those things.
Unfortunately, there is a very real tendency for accounting and financial types to sink a business if they get too much say in determining marketing and operating policies. A friend of mine once observed that accounting is like the view out the back window of a car -- it lets you know where you have been. That's useful, often required. But if you steer the car by looking out the back window, you will inevitably wind up in a ditch. And so it is in a lot of businesses these days. Extreme unbundling of software products for the internal purpose of "cost recovery" management is unwise, counterproductive and, in the long run, suicidal.
In the really old days, the computer manufacturers knew that they were selling hardware, and that hardware is useless to the customer without the basic software to make it work. Not the user-specific applications software, mind you, just the OS and device-specific stuff. They also seemed to understand that the more obstacles they might place in the way of a customer's full utilization of a system, the worse it would be for everyone concerned. Underutilized systems get a bad rap and a bad rep, and it all reflects back on the manufacturer even if it's entirely the customer's fault.
Of course, people were relatively cheap back then, and hardware was relatively expensive. We've passed beyond the people bubble, however, with significant advances in software development tools. If you doubt that, go download a free Web browser from somewhere and figure out how many man hours would have been required to create 15 MB of object code in 1960. And consider that virtually all the Internet software you use has been created in the last five years or less.
I believe that the policy of bundling the OS and all the system software is a sound one. If you bought the machine, the price should have included the essential software to make it function. If you bought a communications controller at a flea market, you should still be able to put it under vendor maintenance and get the communications software at no charge or at a nominal media and handling charge. Someone bought that piece of gear new at some time in the past, and the price they paid should have included the software, so why should it have to be paid for twice? The ongoing maintenance of the software products is an entirely different matter and should be funded from ongoing maintenance revenues. Making the transition from unbundled sofware to bundled poses thorny issues, but those are best dealt with sooner rather than later (if there will even be a "later").
As a purely practical matter, the hard fact is that a wide variety of infrastructure software is completely bundled, completely "free" to baseline licensed users, on virtually all other platforms today. TCP/IP, in particular, is bundled with all unix systems, all Windows 95, NT and 98 systems, all Macintosh systems. Even large mainframes do TCP/IP these days, and though I don't know specifically, I suspect it is bundled there, too. No system that lacks bundled, robust TCP/IP has any future in today's market. If Wang wants the VS to have a future, even just for the sake of several more years of maintenance revenues, TCP/IP must be sound and must be bundled.
The big danger that Wang faces with continued unbundling is that there will not be as many takers as there otherwise would, and the VS will disappear sooner and, with it, the maintenance revenues. A little tinkering with a spreadsheet to see the long term effect of a percent change here or there in the VS market is eye-opening. It reminds one that there is the compound phenomenon at work, and the cumulative effects of small changes, particularly small changes early in the game, can be huge.
Become aggressively pro-active. Build on the considerable existing technological foundation. Make the VS a fully viable player in current and future markets.
27 Apr 07: The New VS has been doing RSF clustering for some time now.
The first time I looked up IBM S/390 information on the Internet, the first thing I noticed was that the 390 isn't a computer, it's a cluster of computers. Aha! Serious, high-end use of the VS also implies clustering, and Wang has the technology for 100megabit/sec FDDI clustering as a standard product. So why not create distinct, identifiable products at the high end, products that include clustered processors, XDMS, Overdrive, and RAID 7 for starters? Something like this:
I have not attempted to carefully design these configurations -- I'm just trying to show that by designating a clustered product, it is possible to include all the elements likely to be necessary or extremely useful without leaving it to customers to figure out that such systems are feasible, and create the conceptual and real-world existence of products whose identities are entirely intangible while their capabilities are very real. Just this effort at marketing packaging would extend the perceived range of the VS in the marketplace, but with very solid, very real hardware and software. Go a tiny step farther and make that RSF in those configurations perform at gigabit speeds and the resulting clusters constitute full, ranking members of the mainframe class of systems.
I would also go so far as to offer very attractive upgrade deals for sites that have already blazed pioneer trails into clustered VS territory, and turn them into showcases of VS muscle and mainframe computing.
17 Jul 05: This was done. The VS6760 and VS6780 were released in 2000, bring the CP18 to the VS6000 lines.
27 Apr 07: The New VS replaces all legacy models of the VS and offers performance up to TWICE that of the VS18950.
There have been rumors of this (Don Winterhalter has mentioned it, among others), but no news of solid plans. The fact is that technological evolution has obviated the need for large VS cabinets in many, if not most cases. Most of the former requirement for physical connectivity (large numbers of coax Serial IOC connections and large numbers of disk drives) has been altered by newer forms of connectivity such as VS LAN Connection, network printers, and disk drives 100 times the capacity of the drives of the 1980's.
What is needed now is to metamorphose the VS into a smaller package, one like the 10-slot VS6000 server box. The processor is not the only concern, though. The VS6000 I/O bus isn't fast enough for CP16 or CP18 processing. The present 64MB memory limitation is too low. The SCSI IOC could stand to be made faster, though its limitation of a single SCSI chain would not necessarily be a limitation when used with multi-host RAID, particularly if the IOC were upgraded to SCSI 3's wider addressing capabilities.
One of Wang's concerns, undoubtedly, is not to position their small VS models to compete with their large VS models. I'm sure that the marketing analysts at Wang have quite detailed and in-depth workups of such things. I would observe, though, that they may not have considered that survival may require a major shift in the scale and cost of VS boxes toward the smaller yet still high-performance VS that is now possible. Intel-based servers have been marching along according to Moore's law, roughly doubling in performance every 18 months. The question of whether or not Intel servers are as good, as robust, as easy to program and manage as the VS, etc., will eventually give way to raw performance for the dollar. To have a chance, the VS must also offer a dramatic increase in performance for the dollar, preferably in smaller packages with smaller footprints, lower power consumption, lower maintenance costs, etc.
This is an exceptionally difficult challenge for Wang, since in-house concepts of product value, product pricing, licensing policies, product scale, etc., all tend to become fixed and to take on a life of their own irrespective of external market changes and even of complete turnover of staff. This is a problem not limited to Wang, but common to all established market players in times of significant paradigm shifts. You can watch this at work in the digital camera explosion, for instance. Old-line camera and film manufacturers are under extreme pressure to cope with the philosophical ground shifting under their markets. Those who fail to see that digital cameras are going to completely destroy the traditional camera and film market will lose, and may never quite understand why. Those who can see that major changes are required in their approaches, the nature of their product lines, their prices, will have a chance. As in Wang's computer market, it is a whole new game in which all existing notions must be reexamined in the harsh light of reality.
Revive VS multiprocessing... (yes, there was such a thing)
17 Jul 05: Too late, but other powerful capabilities of the New VS make up for this.
Since the era of VS multiprocessing, which was also still the era of native VS terminals (and hence the huge VS10000 cabinet, to support all the IOCs and backpanel connectivity), the fundamentals have changed. Small boxes with fast CPUs can now support the user populations that used to require hundreds of coax cables snaking their way to the backs of large VS boxes. Any kind of packaging that will allow VS multiprocessing will by definition also support large user populations, which today are connected via VS LAN Connection or Lightspeed. With improvements to TCP/IP, large populations could also be connected via telnet.
I believe that the scalability offered by multiprocessing is a key factor in evaluating platforms today. Whether or not a customers actually buys MP, its mere availability affords a scalability ceiling above present needs that is more often than not a requirement in most platform purchases.
VS unix... (yes, there is such a thing)
17 Jul 05: Something better and actually a leapfrog over what I had suggested in the 1990s, has now been done: The New VS runs in Linux and has access to powerful Linux capabilities.
The Virtual Machine OS and Wang unix are realities that most VS customers have either not heard of or have heard of only indirectly, through the rumor mill. My guess is that it didn't catch on when it was first introduced because any overhead hit at all was probably economically distasteful 10 or so years ago when VS CPU cycles were much more expensive than they are today. If the only real problem with VM / unix was performance, the newer, faster CPUs and the higher performance/price ratio in late-generation VS processors should make VM / unix more practical.
For those who haven't heard of this before, the VM OS allows the creation of virtual machines and the attachment of I/O devices such as disk drives to virtual machines, and the IPL of individual virtual machines with the VS OS or with unix. It's a remarkable technological achievment that is in use today in the field, primarily in Europe. I think more customers should know about it. I also think Wang should consider actively promoting the concept for the newer, faster models of VS.
Of course, it may be that VS unix isn't the best or most up to date (I don't know). What then of something truly daring like porting Linux or Free BSD to the VS?
Build robust new coprocessors...
17 Jul 05: Better yet, coprocessors have now been virtualized in the New VS. Add as many as you like, up to the slot limit of the virtual VS model you are configuring.
IBM recently announced a co-processor solution that allows its S/390 mainframes to run unix code. Duhhhh!
Build industrial-strength connectivity
Jul 17, 2005: This is being done in the New VS.
I'm considering using an external Linux box to provide large-scale TCP/IP and other connectivity for the VS. I'm not the best one to do something like this, of course. I have very limited resources, and I will have to connect the Linux box by means of the IWS interface. I may even have to forego Linux and use Windows because I have only so many hours in a day.
Imagine, though, a fast, capable Pentium with large-pipe access to the VS. The Pentium can run hundreds of TCP/IP connections and do all the legwork. It can run off-the-shelf web servers and database front-ends and middleware.
Ideally, the co-processor should be on a VS IOC. By the mere modification and/or addition of VS OS code we would automatically and instantly get access to all the devices that can be connected to a Pentium. Have you seen the connectivity and performance of Adaptec SCSI controllers, for instance?
Wang could use off-the-shelf components to beef up the I/O capabilities of the VS and make it a strong player in today's market. A baseline Pentium VS IOC would be the gateway to virtually all the connectivity that exists and will exist in the coming decade. Superfast, superwide SCSI, massive TCP/IP, 100mbps and gigabit LAN connectivity.
Wouldn't that be the logical destination for Wang's original intelligent microcode-loadable IOC architecture? To take advantage of what is now available to be packaged as an IOC?
17 Jul 05: This is all now being done in the New VS, which leap-frogged over my 1990s suggestion to incorporate Unix/Linux on a VS board. Now the entire VS has been virtualized, which was where I envisioned it going from the beginning.
VS emulation in an Alpha (or other fast chip)...
17 Jul 05: Forget Alpha. That was the 1990s. The New VS standardly runs on dual 3.6 GHz Pentium Xeon processors that run circles around the Alpha chip that was the hottest thing when this advice was originally written.
27 Apr 07: The New VS has moved up to Dual Core Xeon and now offers TWICE the performance of the high-end VS18950.
There is a guy in Europe who has a VS emulator running on an Intel PC. It runs unmodified VS object code. I've tried it. It works. It is not optimized, all being written in straightforward C with no assembler. Yet... on a P-200 it runs about as well as a VS6 serving a single user. Meanwhile:
600mHz DEC Alphas are a reality. 400mHz Pentia are a reality. 500+mHz Intels will be a reality in the next year or two. IBM and Intel have both promised 1gHz processors by the end of the century. What is the chance that emulating the VS on another platform will NOT be feasible in the next year or three??? Wouldn't a single-user VS OS running on a desktop PC have some useful place in tomorrow's market?
NOTE AS OF LATE AUGUST, 1998: The experimental VS emulator has been informally clocked at about FAST 1000 (slightly faster than a VS7120, slightly slower than a VS6230).
17 Jul 2005: VS emulation of a limited sort was incorporated into COBOL ReSource in a project that ran from late 2000 through early 2003. It runs well-behaved VS applications within the COBOL ReSource framework. Full VS emulation capable of running the VS OS and all VS applications was implemented in a different project culminating in the 2005 launch of the New VS.
Gigabit RSF...
17 Jul 05: The New VS will have RSF within its first year, using Gigabit ethernet as a transport.
05 Nov 05: RSF code has been written for the New VS and is now in integration testing.
27 Apr 07: The New VS has been doing RSF clustering over gigabit ethernet for some time now.
RSF is nice. RSF is slick. I like RSF. It uses 100 Mbit/sec FDDI (fiber) to cluster up to (theoretically) 16 VS computers. The OS supports RSF for disk and file sharing, cross-machine logons, cluster-wide Job and Print classes. It's good stuff, it works well, and I don't intend to criticize it in any way. I just have one question for you to consider: How many bits per second pass across the system bus of a large VS? You might be surprised. If you guessed a few hundred megabits/sec, you're way too low. Try 4.3 gigabits/sec of instructions and data. Since a substantial amount of data might have to move between VS nodes in a cluster running a monolithic application, my guess is that RSF will have to run at a minimum of 1Gbit/sec to be fully functional. That's why I believe a faster version of RSF would go a long way to leveraging the usefulness of the VS and of RSF, one of the slickest features ever developed for the VS line.
Direct TCP/IP support of PC workstations...
17 Jul 05: Direct support of Lightspeed NVS desktop clients is now a feature of the New VS, eliminating PC gateways and bypassing the bottleneck of the WLOC card.
27 Apr 07: The New VS has incorporated multiple virtual Lightspeed gateways since early 2006. The external PC gateway is a thing of the past.
I believe this is now being released in the context of VS LAN Connection. It also paves the way for Wang (or anyone else, for that matter) to build an NT-based TCP/IP proxy using the Wang IWS API set and the NT TCP/IP API set. That is ultimately how TCP/IP overhead can be moved outside the VS processor.
WSN over IP...
05 Nov 05: The New VS now does WSN over TCP/IP, supporting all WSN/CNS features.
Hmmmm! Wouldn't WSN/CNS take on a whole new meaning if it could be transported over Internet/intranet/VPN? Wouldn't it remain highly practical to keep VS systems linked in the WSN network we all love so dearly for its robust features, if only it didn't require those pesky and expensive dedicated data lines?
(NOTE AS OF LATE AUGUST, 1988: I've heard that this has been done! Someone in New Zealand reported successfully tunneling WSN over IP using Cisco's STUN feature. I'm trying to get specifics.)
27 Apr 07: This is now irrelevant. The New VS integrates virtual TCB/WSN that communicates over TCP/IP.
Better yet, morph WSN into TCP/IP...
Although you might not know it from an outside look, WSN is cut from the same cloth as TCP/IP. It is actually pretty standard HDLC, the mother of all modern transport protocols. Though this might be just a crazed fantasy, I'd like to see WSN morphed into compatibility with TCP/IP. Maybe, with availability of a TCP/IP proxy in an outboard gateway PC, this could represent a reduction in networking code in the VS rather than an increase.
Multi-gigabyte main memory with file mapping like unix...
17 Jul 05: The New VS effectively does this. It runs in Linux and Linux uses all of available memory for mapping files into memory. Put, say, 2 GB of physical memory in a New VS and allocate 512MB to the virtual VS, and Linux will use most of 1.5 GB for file mapping.
Unix on any platform is a notorious memory pig. On the other hand, it does some cute things with all the memory it likes to have. One thing it does is map files to "unused" memory, making them readily available for re-use. On a 1 gb AIX system it is not uncommon to have 500 mb of mapped files (read that as "cached" files) on a most-recently-used basis. If real processes need more space for virtual memory, they get preference. Sounds good to me. Wouldn't an OS enhancement like that be possible if a large VS could handle 1 gb or more of main memory?
(NOTE AS OF LATE AUGUST, 1998: Rumor has it that the new VS18000 will accomodate up to 2GB of main memory)
17 Jul 05: It does, but the New VS goes one better: it can virtualize up to 2 GB of VS memory while still having more (up to at least 12 GB) for file mapping and caching.
Open SCSI...
17 Jul 05, updated 27 Apr 07: Yep, the New VS does this, too. It uses standard SCSI devices, but even better, it includes RAID and up to 2.1 TB of internal, fault tolerant storage. External storage is essentially unlimited.
Wang still has its SCSI controllers check for a proprietary Wang firmware "signature" when polling the SCSI chains for devices. I understand the technical reasons for that. The Wang implementation of SCSI is reportedly quite robust and quite exacting. Run of the mill non-Wang SCSI drive firmware can and does cut corners, omit SCSI functionality, report errors ambiguously or erroneously, and a host of other troublesome failings that can vastly complicate the orderly management and error logging of SCSI disk drives. Still, the marketplace seems to be saying that it doesn't care. Wang is now in the position of trying to sell the marketplace a level of SCSI excellence that buyers don't understand and don't want to pay for. Maybe it's time to recognize market realities, continue to offer the good stuff, but remove the obstacle in the SCSI IOC microcode and just let the customers know that they may be buying a lot of trouble if they go the cheap route.
After all, most buyers of small computer memory aren't willing to pay for parity memory these days. Some pundits sagely observe that this is because today's memory chips and subsystems are so reliable that parity is no longer necessary. The real reason, though, is that most people buying small computer memory today have no clue what parity is or why they should pay for the extra bit, so they buy the cheaper non-parity memory. In that kind of market it doesn't make a lot of sense to try to force the buyer to do what's right. It just gives the customer another reason to avoid the platform or vendor altogether.
OS/RAID integration...
17 Jul 05, updated 27 Apr 07: The New VS does this, too. The primary New VS platform is the Dell PowerEdge 2900 with integrated RAID with 256 MB cache, its own battery backup for the cache, and up to 2.1 TeraBytes of internal disk storage. VS disk accesses are mapped and cached by Linux and by the RAID controller. Modern disk drives also have substantial onboard buffers.
At least some unix systems can have disk space added to mounted volumes during the production day. The volume, of course, has to be a virtual volume, typically part of a configurable, multi-host RAID subsystem. How do they do that, anyway? It's really not all that difficult. The OS just has to have the ability to be told to resize a mounted volume. To do that, all it has to do is lock the VTOC long enough to add the new space to the free block chain. The VS already has OS-level support for locking the VTOC. Try running LISTVTOC against a volume and accessing the volume from another workstation. You won't gain access until LISTVTOC has finished extracting the VTOC for analysis.
This kind of on-the-fly feature probably would have curled the teeth of 1970's / 1980's system software designers, but hey! -- it's becoming a ho-hum common thing today.
Fully publish APIs and interfacing specs across the board...
17 Jul 05: The New VS addresses much of this by bringing the VS Operating System into the open systems world. There are no more proprietary VS devices. You can bring your Wang 4mm tape drive forward to the New VS but you can also add things like a SuperDLT 320 GB tape drive to the New VS. Or Fiber Channel for connection to enterprise RAID.
I think the jury came in a long time ago on this one. The PC world, the unix world and the Internet have clearly shown that open specs win and closed specs lose. With open specs, more players enter the market fray and more products result. With more products, the customers have more choices and are able to better make a fit. The more choices and resources the customers have, the more robust the market environment for a given platform or system, and the longer its potential lifetime. Open specs are not a guarantee of platform longevity, but closed specs are a powerful obstacle to it.
Give small VS's and all software to any qualified programmers who want them (just sign this little development-only agreement...)...
17 Jul 05: The New VS program makes it possible for bona fide developers to get a developer license for the VS software and the New VS enabling software.
I keep thinking about all those programmers with heavy VS experience... some of whom would still like to develop VS software, while there are undoubtedly machines like VS5000's going on the scrap heap. Maybe those programmers are contrarians and resisters of mass moo-cow movements and technological fashion trends, like I am, but believe me, they're out there, and the waste is tragic. Hell, if someone would support me in a reasonably comfortable style, I'd program for free, just for the fun and satisfaction of it. Programmers and pilots count among their number a surprising fraction who are in it for no reason other than that they love it. Pilots love to fly. True programmers love to build software. I'm not the only one. There are people out there who would happily write VS code, and some of it might even be useful to Wang or to the installed customer base. Some of it might even be worth paying for. Some of it might, just might, make a crucial difference at a key point in time.
Create migration paths to the VS, not from it
17 Jul 05: Some of this is now being planned.
How about IBM flavors of RPG and DEC flavors of COBOL and BASIC for the VS? (want to migrate? just recompile!) You may have noticed that Microsoft and others often provide application import filters for foreign document formats, but rarely provide export filters if they can avoid it. The reason is simple: make it easy for applications/documents/whatever to migrate to your platform and don't do anything you don't have to to make it easy for applications/etc. to migrate away from your platform.
Wang has been doing just the opposite, part of its acquiescence to the decline of the VS market, no doubt. Wang has even written admirable, capable packages like COBOL/RESOURCE, which eases the migration of VS COBOL applications to several unix platforms. But... huh? Instead, let's see some packages that allow migration of AS/400 and DEC VMS applications to the VS, especially now that the future of DEC's large platforms is, how shall I say it... In doubt? And what about all those mildewed HP systems out there?
Make VS applications survive beyond the VS platform
17 Jul 05: It's done. The New VS runs all VS applications with no conversion, no migration -- just restore from tape or copy from disk and IPL the New VS to run your VS applications.
Heresy, perhaps, but... Doesn't IBM claim that the AS/400 now has an interface layer near the bottom of its OS that can allow things like the Macintosh OS to run on the AS/400? Has Wang thought of looking into the possibility of immortalizing the VS OS by getting it to run on other platforms?
17 Jul 05, updated 27 Apr 07: This is exactly what has been done. The New VS runs the VS OS and all VS applications on Linux platforms, primarily the Dell PowerEdge 2900, but also IBM xSeries (IBM's Intel servers) with no conversion needed.
Metamorphose the VS CPU
17 Jul 05, updated 27 Apr 07: We skipped over this by virtualizing the entire VS and its principal coprocessors.
Instead of building basically the same, microprogrammed CISC chip using finer and finer lithographic resolution, why not revisit the fundamentals and see if something might not be gained by supporting the VS instruction set in a radically different way? Yes, I know I may be all wet here, and I know that VS Engineering is actually doing a lot more than merely shrinking the chip, but gosh, forgive me for wild runs of fantasy: might it not be possible to double, triple, quadrulple the processor speed with a radically different approach?
Does a high-end VS processor *really* have to cost $150,000-plus? I'm beginning to do objective benchmarks of the VS processor to compare it with other popular processors. While it's too early to really say anything definitive, my first results have been puzzling. The effective, bottom-line cost of MIPS plays a part in the systems marketplace. If the VS does not do as well in objective measures of performance as the technology allows and nothing is planned to remedy this, the VS will ultimately fail in the markeplace.
17 Jul 05: The New VS on Dell PowerEdge 2900 is now at fully TWICE the speed of the VS18950 (the fastest legacy VS ever made). Since there are presently no VS systems operating at greater than the capacity of the VS18950, the New VS can satisfy all present capacity requirements, and then some. Further speed improvements are expected.
What about bringing the VS instruction set and OS to the state of the art of performance? Is this really beyond consideration? Is it too late for this? Don't say it's so!
I wonder if Wang has considered things like working with IBM to set up the AS/400's emulation layer to emulate the VS? IBM claims that the AS/400 can run things like the Macintosh OS... why not the VS OS? If Wang really sees the VS hardware base shrinking at the reported 25% per year until it is gone in a few more years, shouldn't they have some interest in perpetuating the widely-loved VS OS, the ease of operation and good user interface, to support the huge amount of existing VS software on any available hardware platform?
17 Jul 05: No longer necessary. It has been done in the New VS.
I've also thought of the concept of porting Linux or Free BSD to the VS, and of porting the VS OS to Linux or Free BSD. Ambitious, slightly deranged thoughts, it's true, but it's thoughts about what could be done if only we consider the possibilities that often yield up viable avenues for exploration and development.
17 Jul 05: My wildest dreams have been realized in the New VS. It runs in Linux or Unix and achieves 100% binary compatibility with the legacy VS, allowing it to run the VS OS and all VS applications that don't depend on obsolete or otherwise unsupported hardware.
More on I/O muscle
The idea that is currently nagging at me from my back burner is using a fast Linux or Free BSD PC as a VS co-processor, particularly to handle massive TCP/IP efficiently (this is another presentation of the Industrial Strength IOC pitch I made a few paragraphs earlier). It would require a large data pipe into the VS, which can be accomplished in at least three different ways, all of which are possible:
1. Wang's IWS support, which has Windows API's to allow software in a PC to use WLOC and 928 to communicate with tasks and DMS on the VS. This works, and is the basis for products such as the VS LAN Connection PC gateway that provides virtual terminal services to up to 64 LAN PCs through a single gateway. Support for the IWS interface would have to be ported to or rewritten for Linux or Free BSD as a new device driver. The IWS / 928 interface is not really "big pipe," but at roughly 4.5 Mbits/sec and with intelligent blocking, it is not too shabby. Think of it has half a 10mbit LAN dedicated to interconnecting just two hosts -- the PC gateway and the VS.
17 Jul 05: The WLOC has now been completely bypassed in the New VS. Lightspeed gateway functionality has been integrated into the New VS, so LS desktops can communicate directly with the New VS at higher speed and without gateway PCs. Gigabit ethernet is now the rule for higher bandwidth, and the New VS comes standardly with two Gigabit interfaces. More can be added.
2. SCSI peripheral interface hardware such as is used by Lightspeed in their SCSI version of the LS gateway. This would require writing a completely new unix device driver to mimic a SCSI peripheral, and some fairly straightforward device I/O coding on the VS, perhaps in a background task like the IWS components do for Wang's 928-based IWS.
17 Jul 05: This has also been bypassed. The connectivity problem of the legacy VS no longer exists in the New VS, which uses Ultra-320 MB SCSI and Gigabit and Fibre Channel networking. It also has its own Linux tape module to seamlessly integrate newer SCSI tape technologies.
3. A new type of VS IOC. This would require Wang's support, although there are several other companies with experience and past products using direct connection to the VS I/O bus. EMC, the people who used to make memory, clearly know (or knew) all about the VS memory bus. SEEK, who make their own VS SCSI IOC, obviously know all about the VS I/O bus. Follow this, though... it's a contagiously delicious concept:
17 Jul 05: Since IOCs have been virtualized in the New VS, there are no more hardware considerations such as existed in the legacy VS, and no more purchasing decisions for IOCs... just configure as many as you like, up to the I/O slot limit of the virtual VS you are configuring, usually 15. IOCs have essentially become free, and virtual disk drives have become dirt cheap since you can make them at will in your larger-than-life RAID on the New VS.
The idea here would be to use pretty standard logic on the VS side -- DMA and interrupt stuff... all logic that exists in several forms throughout all the VS IOCs -- and interface that to a Pentium chipset on the same board such that the Pentium can act as an embedded processor to completely control the behavior and characteristics of the IOC.
17 Jul 05: All bypassed. The New VS leapfrogs over the issues I was trying to deal with in the 1990s to make the legacy VS evolve into something new. The New VS just does it. No evolution is required.
Then, regardless of which methodology is used from the list above, comes the really interesting part: Instead of supporting a "front end" that talks to conventional VS devices, we use the PC's native I/O to talk to real world devices, including all manner of state of the art peripherals and, most importantly, 100 mbps or better LAN-based TCP/IP to support *efficient* telnet-to-VS, ftp, web service (mostly offloaded to the PC) and other neat things. At that point there would be no hardware constraint preventing the use of any and all PC server hardware on the VS. Wang could breathe a sigh of relief and withdraw from the gnarly business of engineering and supporting low- volume VS peripherals and concentrate on the software to support high-performance PC server peripherals in the VS OS.
17 Jul 05: Done. Done by virtualizing the entire VS and its commonly used IOCs.
This is the kind of thing that mainframes are learning how to do, although I have no idea of the technical details of how they are implementing it. The RS/6000 I support does its backups through the ADSM package to an IBM mainframe. From looking at the data transfer stats and messages, I can clearly see that the RS/6000 and the IBM mainframe are linked by TCP/IP over a 100 mbps LAN. Backups are done at an average of 4+ megabytes per second.
17 Jul 05: Done. If you want to put high-performance backup devices on the New VS, you can do backups at 10, 20, 40, even 80 MB/second.
I also wonder why they don't consider an alternate form of RSF in which they emulate IBM fibre clustering packet protocols to establish *some* kind of interoperability with AS/400 and mainframes. It would be similar to the things Wang has done so well in TC, for RJE and SNA, in which the VS pretends to be some kind of standard IBM component, at least for some subset of the defined transactions.
17 Jul 05, updated 27 Apr 07: This has now been done. Virtual RSF uses TCP/IP to interconnect nodes in a New VS cluster. This also makes it easy to cluster nodes not only in different New VS machines but in the same New VS machine. VS/VM will probably also be supported in time.
IBM has put a co-processor into the AS/400 architecture to run NT and compete with PC servers. They've put something into the S/390 to run unix applications. There must be enough hooks and handles in the VS to do some cute things there, too. It's a matter of imagination, optimism, and determination. And some funding, too, of course.
17 Jul 05: Poo! The New VS just virtualizes the entire VS, bypassing issues of how to beef up the legacy VS and running at speeds up to twice that of the VS18950..
Summary
I disagree with the notion that it makes sense to allow the engineering heritage, body of knowledge, and experienced staff (even including recently ex-staff) to wither and disappear. I also disagree with the notion that what is left of VS Engineering is best utilized by finding some role for its resources in the new, non-engineering business of Wang Global. At the same time that Wang is embarked on a new course that disdains the engineering and manufacture of hardware, other companies are starting up with next to nothing to do precisely that. In this diametrically opposed set of viewpoints, others would give their right arms to start with an existing body of knowledge and experience, a significant installed base, and the people who built the hardware and software that challenged IBM. To almost anyone but the New Wang, VS Engineering would be a significant bootstrap up to getting into the business of building first-class hardware. Differences of viewpoint and opinion are what make markets and opportunities.
17 Jul 05: In the years that have passed since that was originally written, the VS hardware has dropped below the critical mass of installed systems to justify considerable engineering outlay to overhaul it. But the New VS solves that by replacing the legacy VS outright with modern server hardware while retaining full compatibility with the VS OS and all VS software that doesn't depend on obsolete or otherwise unsupported legacy VS devices.
Wang Global executives have stated that the VS is in decline because it is a proprietary system. This is demonstrably incorrect. If being proprietary were the basis for decline, the IBM AS/400, one of the most proprietary systems ever to have hit the streets in modern computing, would be in decline. Instead, it is still on the rise, cresting 250,000 installed systems. If being proprietary were the yardstick, the IBM System/390 and other mainframes would be in decline, but they are not. In fact, "proprietary" has less meaning today than it has ever had in the past, for two compelling reasons:
17 Jul 05, updated 27 Apr 07: In the years since that was written, significant increases in Intel x86 CPU speeds and packaging of Intel CPUs into robust servers such as the Dell PowerEdge 2900 have changed the parameters. A Dell 2900 with a single 3.0 GHz Dual Core Xeon processor can now run VS software at FULLY TWICE the speed of the VS18950, with fault-tolerant RAID storage, optional fault-tolerant mirrored RAM, Gigabit ethernet, remote control that can monitor and control the server from power up through full operation, and other robust capabilities.
Wang has held the keys to the kingdom in its hands since the VS was first released. It has been one of the major R&D founts of the U.S. technological economy since Dr. Wang did seminal work developing core memory. Since then Wang has given the world electronic calculators, word processing, digital imaging, and affordable mainframe data processing. All that is needed to return to that pioneering path of excellence is vision. The new vision at Wang Global is networking services. That's fine, and it seems to be working out very well for them. Personally, it bores me to tears, but to each his own. I say let's find a way to reconstitute what's left of the exciting old Wang before it's gone altogether, and go out and give IBM a run for its money.
17 Jul 05: Everything has changed since that was first written. The New VS provides the ongoing basis for the continuation of the VS software technology and will keep the VS software human resources on the job. For the first time in about 15 years the VS OS and other system software will have the opportunity to get new attention, new features, and to move forward into the open systems world with new connectivity.
So, some of the things I would consider doing with the VS part of Wang, were I in a position to do so, are:
If you think this makes sense, I'd like to hear from you.
Thomas Junker
I have indeed heard from quite a lot of people in the last nine years, and I greatly appreciate the encouragement and many positive comments . No one, however, stepped forward to help make any of this happen. In 2003, 2004 and 2005 I did it myself, finding and organizing the financial and technical resources to give birth to the New VS. TransVirtual Systems was created in mid-2004, I went to work for TVS in November, 2004, and the Lightspeed NVS product line was acquired from Lightspeed Systems and another company, Lightspeed NVS, formed in late 2004. TVS and Getronics signed a multi-year agreement in Jan, 2005 to work together to bring a New VS to market. TVS now has ten people, between full- and part-time participants, and will soon be larger than the remaining VS staff at Getronics.
Some of the comments I've received that suggest I am not alone in thinking that a great opportunity is being missed:
27-Nov-98 – I found what you had to say on saving the VS very credible. Long live the VS.
24-Nov-98 – [Your site is] a blast from the past together with some hope for the future, for one of the best development environments the world has ever seen.
28-Oct-98 – We have a significant investment in WANG and PACE that has served us well. So we are very interested in your work. –D.O.
25-Sep-98 – I hope that some "white knight" appears and gives the VS more support than Wang is willing. There's certainly precedent -- Mentec has done wonders with the PDP-11 operating systems and patents that it purchased from Digital. –J.B.
14-Jan-98 – I am a mainframe (IBM 9672) systems programmer since 1965, just came upon the Wang VS about ten years ago for my home business. I loved it from the start because it was very IBM mainframe like (batch initiators, job queues, print queues, all the mainframe languages... even the Assembler code looks amazingly like the IBM mainframe). –B.S.
16-Oct-97 – I'm very interested in the VS Web Server. It's products like this that might delay or even stop our migration to Unix client server technology (that seems to have more than just a few problems). –K.J.
02-Sep-97 – Good job, in fact, great job. I still deal with Wang VSes daily. –T.G.
26-Jun-97 – Still a great machine, and a real joy to write code on. I created many really good systems and my users were all happy campers. Again, nice site, and keep the interest going in the VS! –J.C.J.
I've received tons more comments like these through the years, and they continue to come in. It became too much work to dig them out of the email archives, so I stopped adding them here in 1998.
![[home]](homebtn2.gif){kind=small}
Up to The Unofficial Wang VS Information Center
(If you came here from there, use your browser's BACK button instead)