VM/CMS price/performance

Efficient, low-cost platform

  1. Traditional emphasis on performance
  2. IBM's premiere mainframe interactive environment for all 370/390 systems
  3. Low cost compared to PC and Unix (surprise!)
  4. Low staff, support costs

A heritage of efficiency and value at low cost

It's a traditional fact of VM/CMS that it is remarkably efficient. VM still retains this wonderful property -- IBM tracks path lengths of key system functions, and expends considerable effort to ensure they don't balloon with new releases. Good function isolation also helps control path lengths. VM/ESA shows that systems providing significant new function can be much more efficient than predecessor systems. In the 1970's, VM pioneered highly responsive interactive systems, showing the world that most transactions should be delivered with subsecond response time. VM remains true to this heritage today.

Modern VM algorithms are flexible enough to be effective on both small and large platforms. Other systems are not. VM fits without pinching on small platforms like the Personal/370 or Personal/390 (PC Server 300 System/390) yet can run on a high-end ES/9000 or current CMOS box, and take full advantage of the large system's capabilities. No other operating system has such a range of compatible performance, with the exception of Solaris going from small Sparc up to their E10000 - but you don't run that system as a single image, to ensure reliability. With VM you can.

In contrast, MVS doesn't run well on small CPUs, since it hardly fits on them, and doesn't support inexpensive FBA DASD. It also seems to me, based on observations at my site, that MVS doesn't do as good a job with N-way multiprocessor effectiveness as VM, so its throughput is limited on large complexes as well. I think this is partially a problem with MVS itself, and partially the consequence of applications like CICS, that do most of their work in a single task and therefore derive little benefit from multiprocessors.

IBM's announcements of 390-based systems with many processors focused on MVS. I think this was a mistake. Why specify only one system when it has the effect of excluding another one you sell, especially when the other system (VM) can probably exploit these new processors sooner and with less difficulty. There was a real shock when companies learned what it is like to run MVS on 10 MIPS CMOS engines. (I wrote the above material in 1993; subsequent experiences with slowish CMOS running MVS have corroborated my lucky (or educated) guess. Faster CMOS in 1997 made it possible to run MVS well on CMOS machines).

VM, of course, happily runs on CPU engines of speeds slower than 10 MIPS, and will do nicely on the parallel 390. CSE, ISFC, APPC/VM, cross-system SFS and DB2/VM, cross-system IUCV, all make VM a natural system for horizontal growth on highly parallel 390. IBM should announce a statement of direction for this environment, and publicise it as a way of providing reduced cost of computing for general-purpose systems, rather than the specialized environments provided by the parallel query and transaction servers under MVS.

Contrasts are stronger with other operating systems. Unix runs on a wide range of processors, but has too naive a scheduler, memory manager, and so on, to exploit systems with many active processes and I/O devices. Both VSE and Unix (a bizarre juxtaposition) suffer from large systems effect. Unix developers are just beginning to address this. Sun Microsystems hired Amdahl Corporation to boost its large system performance and make Solaris industrial strength; but didn't they tell us that Solaris was already industry strong? It's funny - Sun is now selling their E10000 machine, which is essentially a mainframe running in an LPAR-like environment. Didn't they proclaim that large, shared computers are bad ideas? Well, they're smart guys, and they saw the light, too.

Sun provides a subset of LPAR on the E10000 - doing in 1997 what IBM did in 1987 on hardware and in 1972 in software via VM. This environment is limited by the fact that all the system images have to run the same operating system (there is only one - Solaris - that's why), and you can't share a CPU engine among Solaris images. Not up to par with mainframe virtual machines!

Actually, AIX and Solaris have made advances in this area. Nonetheless, these systems have a long way to go before they scale up well on anything other than specialized workloads. As an inveterate performance hacker with experience on multiple operating systems and platforms, I find the behavior of my Unix workstation exasperating. The disk rattles and response is sluggish at moments that really have no basis in stress or load. Primitive memory and storage management algorithms hamper these systems. There is wide-spread refusal to share a Unix system between unrelated applications because it becomes very hard to prevent them from slowing or crashing one another.

Large systems effect reduces the effectiveness of operating systems scaled up from simple to complex environments. Process and I/O scheduling and memory management require increased sophistication to support thousands of processes and arrays of I/O devices. It takes special consideration for lock management, serialization, and multiprocessor cache-line interference to effectively manage multiple CPUs. Linear running time algorithms are fine when 20 processes or users are on a system, but break down when the same system has 2000.

VM has already been through the seasoning needed to avoid large system effect: it no longer uses order-of-N algorithms for its critical path functions; the elegant generalized hash methods introduced with VM/ESA are an example of this. It has also achieved considerable maturity in its ability to drive multi-CPU complexes under real workloads.

No Unix implementations have achieved this (despite claims to the contrary) for general work mixes, and it is possible that Unix will never avoid large system effect until its kernel and process model are replaced. NT shows signs of being able to scale up to large systems in the next few years. Unix scales better than NT today, but this advantage is temporary. It's already fun to see Unix fans under the same attack they placed on mainframes! I believe that NT market share will grow dramatically at Unix's expense.

Benchmarks showing high multiprocessor efficiency running a compute-bound application miss the point, since all operating systems are efficient when 99% of the time is spent inside application code. In descending order of truth, there's lies, damn lies, statistics, and benchmarks!

Regarding Workstations and PCs

The explosion of desktop computing, which competes closely with VM, is a platform issue rather than an operating systems issue. People are leaving mainframes, sometimes because they want to leave MVS and VM but mostly because this gives them the chance to run on apparently far more cost-effective PCs and workstations. In some cases, however, the savings are far more apparent than real, and it's our responsibility to show when that is true.

First, so-called client/server computing (frequently defined as different from mainframe computing, even though mainframes make excellent servers) is much more expensive than traditional mainframes or minicomputers. Research from Gartner Group, Forrester Research, ComputerWorld's Charles Babcock, and many other industry analysts and observers have come to the conclusion that C/S applications cost as much as 2 1/2 times as much as the same application delivered on boring old mainframes. This is consistent with costs observed at my company. The recent drop in mainframe prices, reducing price per MIPS to 1/6th the cost of the early 1990s completely eliminates the old argument that mainframes are "more expensive". It's just not true.

Clearly, some interpretation is required: if you're writing term papers or inter office memos, it's cheaper to get a PC and run a word processing package. If you're doing some personal number crunching, it might be cheaper to get a PC or Unix workstation and let it grind numbers all night long. But, once you start to provide production services, PCs and Unix systems start to get much more expensive. The costs are on the people and software side, rather than hardware (so they show up differently in budgets), but they result in a far higher total cost.

When you have production applications, you have to build a distributed infrastructure to do all the things that were done in the glass-house, raised floor world. It's too expensive and a source of chaos to let either business professionals do it, even if they're capable, and local teams of system administrators soon cost more than your mainframe. You need to provide services like installing the operating systems, installing products on servers and desktops, making sure that servers are up and running, backing up all data (and making sure you can restore it or survive contingencies ranging from a hard disk crash to an explosion), scheduling jobs, administering userids and security, and many other tasks.

The greatest costs come when you try to build the same type of robust industrial strength computing environment that is present on the mainframe. The dizzying complexity of distributed system management, plus the cost of designing and coding distributed applications is staggering. It is far more expensive to build the infrastructure for these systems, than the computers themselves.

Oh, since Unix and PCs are so insecure, you also have to spend lots of money for firewalls, isolation rings and routers, virus detector software, and lost staff time dealing with them (or being out of operation because of a successful attack).

The allure of cheap MIPS

Departments purchase and amortize their own desktop computers rather than pay chargeback to a central MIS organization. This is an attractive local optimization for many departmental budgets, even though the overall enterprise hardware expenditure may actually be higher. It is also attractive when there is ill-will between user and MIS departments.

Cheap MIPS are often cited as the basis for migrating off mainframes, despite the sharply reduced cost of mainframe CPUs. Too many people compare MIPS across architectures: a 12.5 MIPS Sparc 1 (which lacked an integer multiply instruction) or an 18 MIPS Intel 486 simply cannot be compared directly to a 3090 CPU engine, despite similar MIPS counts. Similar considerations apply with higher-rated, more recent boxes like current Sparc, Pentium and mainframe systems. Different architectures' instructions each do different amounts of work.

RISC systems like Sun, HP, MIPS, and RS/6000, have higher published MIPS rates than equivalently powered traditional (CISC) processors like the 370 family. This makes them look much faster, even though each instruction does less work. RISC machines do not have, for example, instructions to copy or clear blocks of storage. How many instructions on a PC or Sparc does it take to do the work of a Move Character (let alone a Start Subchannel?) Many RISC machines had neither floating point arithmetic nor multiply instructions. Sparc 1 stations, for example, have no integer multiply instruction. (I just read in ACM SIGARCH that the 1999-announced Intel 64 bit architecture lacks integer multiply, and I'm amazed). The often-quoted Dhrystone benchmark, which largely times subroutine calls, also exaggerates PC and workstation CPU speeds. Sun architecture, for example, uses overlapped register windows for fast call linkage, and is particularly well suited to this benchmark. Real workloads include the cost of context-switching between users and kernel, discarding and reloading cache and virtual address translation buffers, and other very important factors that don't show up in a Dhrystone or Specmark.

Benchmarks are so easy to manipulate, too. For example, my frivolous Gallstone benchmark on VMSHARE uses 370's most RISC-like instructions, and rated a 3090S processor (normally rated at 17-18 MIPS) at 45 MIPS! Eric Thomas's MIPS benchmark, more carefully written, measures a 3090S engine at approximately 69 MIPS for some instruction sequences, and as slow as 2.3 MIPS for others. The variance in ratings on a single processor indicate how futile it is to use MIPS to rate performance across architectures. In fact, Eric's benchmark clocks a single ES/9000 9021 engine with instruction rates between 6 and 850 MIPS (that's right - for a single engine of an ES/9000 900!). I get similar results on recent IBM processors like a 9672. These types of performance comparisons are fun but not terribly meaningful.

In the competitive market for workstations, the same vendor tricks for manipulating benchmarks and providing artificially good results are being used now as has been used in the mainframe market (for example, having the compiler recognise a benchmark code and generate pre-canned results!) Every once in a while a little scandal erupts erupts when it turns out that one of the chip manufacturer's benchmark results was rigged to inflate the performance numbers they can publish in advertisements. Another good trick is to quote peak instruction rates (especially for floating point) that can't be sustained with any real workload. There are so many ways to be creative in this area!

CPU power comparisons relating mainframes to workstations undervalue mainframes, since they do not consider processing performed by mainframe channels and control units which must be processed directly by workstation CPUs. This burden does not show up on CPU-only benchmarks like Dhrystone and Specmark, but is extremely relevant for real-world applications that have high I/O requirements. Mainframe computers are actually complexes of computers; many MIPS of capacity are present in channels, controllers and intelligent devices. A processor complex built around a 400 MIPS ES/9000 might really contain thousands MIPS of capacity, if channels and control units were included, and if MIPS actually meant anything.

Nonetheless, it is beyond question that current Pentium family and RISC processors provide very substantial computing power. I have a SPARC and a Pentium on my desk, have server applications running on both of these architectures, and I have a very good apprecation of what they're good at. They are outstanding for keystroke and mouse movement responsiveness, and for high-bandwidth graphics, motion, and audio. These things are done far better on PCs and workstations than on mainframes. They're also very good for number crunching. Unix's (including Linux) mature and fast TCP/IP stack makes Unix very attractive for Internet activity. Competition in this area make PC and Unix servers very good web platforms. It's worth noting that Sun Microsystems made the investment to dramatically improve its TCP/IP performance, and assigned a large (about 30 developers) group to this task - and doubled TCP/IP performance several times in Solaris 2.x. This was a very smart move, which other vendors would do well to emulate.

However, there are domains in which workstations and PC's are woefully inferior to mainframes, and that's system capacity and I/O bandwidth. Large mainframe systems have no problems handling thousands of interactive users doing different things, or many thousands of users doing the same thing in a transaction processing environment, or running multiple batch processes. Mainframe hardware, and mature operating systems resource managers are far superior to Unix or PC systems for large workloads. Mainframes' channel and control unit architecture let them drive hundreds or thousands of I/O devices at high I/O rates. I/O is the limiting performance factor for most systems.

There are applications I'm familiar with in which long-attempted Unix migrations have been hampered by Unix systems inferior I/O capabilities (on recent, high-end Unix servers). I've observed order-of-magnitude differences: a 56,000 record update taking eight hours on Unix, 48 hours for a 1.3 million record database update, and 5 days for a larger master file. These take 8 to 20 times as long as they do on VM.

Cost effectiveness

Cost-effectiveness evaluations for the different architectures often fail to consider the typically low utilization of most workstations. Actual cost-per-MIPS values are actually much higher than purchase cost divided by instruction rate, if workstations spend most of their time waiting for a single user's next keystroke or mouse movement. Mainframes, on the other hand, are manageable resources. that are kept at high levels of utilization, ensuring that capital expenditure provides proper level of returned value. An idle desktop system represents non-recoverable resources, while an idle user on the mainframe merely makes more resource available for other users.

Additionally, there's the factor of computer-envy that afflicts many of us. Naturally I want the latest, fastest PC available on the marketplace, and must discard my no longer trendy, former top of the line machine every year or so. Do you still use a 486 on your desk (of course not - it could barely run current Windows. Office, and browsers), or did you traded it in for a Pentium? Have you replaced your 120Mhz Pentium with a 300Mhz and then a 500Mhz processor? Pretty good for machines that are idle almost all day long. Don't you lust in your heart for every fire-breathing new machine you see advertised in the latest computer magazine? Aren't you already contriving a reason to buy a 700 Mhz Pentium III or UltraSPARC? Does every person in your office have their own 32X CDROM, laser printer, scanner, modem, and fax card? What does that do to the low cost of PC computing? Believe me - I'm not exempt from this, and you should see the little computing facility I have at home (though I dignify it by calling it a "lab").

Also, have you bought enough word processor, personal database, spreadsheet, presentation graphics products? How about C++ compilers (naturally, the expensive Professional or Enterprise editions, not the $99 versions), Web browsers, backup tools, code libraries, application developer suites and so on? Take an honest look at your PC or workstations and figure out the size of investment it represents. (You did buy all that software, instead of "borrrowing" the CD from a friend, didn't you?)

The cost of making it robust

Another type of efficiency is the size of the staff needed to support a computing system. Payroll is the biggest budget component of most companies, and most data processing organizations (which you would assume to be capital intensive). VM requires only a handful of staff to support a large number of systems and users. The comparison with MVS is direct and easy, since MVS requires a horde of staff to run it.

This seems to be even truer with PC and workstation environments, where every LAN or workgroup requires at least a part-time guru or administrator. Unix seems to be particularly labor-intensive, requiring a lot of skilled staff to make it run. Remember, Unix became popular at universities where there where plenty of students willing to work for little or no pay, and whose productivity was irrelevant, and (sigh) actually enjoyed the fact that Unix commands were mysterious and difficult.

My company has many times more staff working on Unix infrastructure than VM and MVS (Unix is much more staff intensive than MVS). Unix staff had already grown large even when there was little production work running on Unix, and therefore less visible effect and a far smaller business scope and number of clients to support (one of the business unit's senior managers was astounded when I pointed this out). I can't even begin to count the army of people supporting personal computers in my firm (at least we have thousands of them to explain the massive staff commitment), though, come to think of it, I'm the one that installed Solaris, MS-DOS, Windows, Windows NT, OS/2, and all the other software on my machines.

What complicates the picture is that their time is too easily overlooked in measuring staff requirements and true workstation costs. A large company may have hundreds of people working part-time as system administrators. What is especially shocking is that high-paid knowledge workers are doing this instead of clerical or operations types. I know of cases in which professionals earning over $150K per year are their own part-time operators, a dreadful expense. They don't do a very good job of it either (both backup and primary copies of the data are often in the same room, so they can be burned in the same fire, and drenched by the same water to extinguish it).

Cost comparisons favoring workstations also tend to be flawed because they compare mainframe chargeback to workstation acquisition costs, neglecting the staff costs and other services rolled into chargeback. Costs for operators (somebody has to do it for each mini-datacenter), hardware planning, contract management, and so forth are simply omitted.

A big omission is the cost for disaster recovery. In mainframe sites this service is provided by the data center and funded by chargeback. In distributed systems this is an add-on cost that can double the cost of the workstation environment. As a result, many LANs and workstation systems aren't properly prepared for disasters, as demonstrated by outages at several companies after the World Trade Center bomb explosion. Mainframe systems tend to be backed up: their owners have paid the expense for disaster recovery, and have contingency arrangements that are periodically tested. Cost comparisons between mainframes and distributed systems must include costly but necessary facilities provided by centralized datacenters, or account for the losses that may occur if no disaster facility is provided. Disaster recovery is also harder for distributed systems: it's much easier to pick up a few rocks than a hundred pebbles.

In the last few years, IS organizations have stepped up to the job of providing true datacenter-style support for distributed systems. A lot of my efforts for the past several years have been in this area, and I've been deeply involved in distributed infrastructure and support. We're finding out that Unix and PC systems can be automated and backed up, and so forth, but it's really much harder and more costly than mainframes. IS organizations have made substantial investments in staff, hardware, and a wide range of products and strategies like DCE, CA-Unicenter, Tivoli, OpenView, NetView/6000, SunNet Manager, Legato, and so on. When end-users drove the installation of distributed systems, system management jobs often didn't get done. Now IS is chartered to do it, and we're both providing these services and finding out how costly it is to do so.

Look at any of the trade magazines, and see the hundreds of competing products, methodologies and tools eagerly bidding for your dollars. They exist, and are purchased, despite their awful cost and complexity (distributed system management and programming is much more complex than MVS or VM management and programming), because they are so badly needed.

In summary, comparisons must include total life-cycle costs to determine true cost effectiveness. Mainframes are more cost-competitive than popular perception would have it. IBM is also aware that they must dramatically reduce the cost of ownership of their systems. CMOS mainframes and the P/390 provide good reasons for institutions to revisit their notions of cost.

Reducing cost of ownership

Despite VM's wonderful capabilities, and the fact that workstation technology is more expensive than many claimed, VM has the disadvantage of running on unfashionable mainframe equipment with a high cost of entry. In order to make VM competitive with other platforms, IBM must reduce the entry and recurrent costs for running VM, and make it possible for VM to run on hardware platforms that have captured the popular imagination.

Two methods are emerging that can reduce VM's cost of computing: the Personal/370 and 390, and the CMOS-based highly parallel 390 systems IBM is now beginning to produce. As I mentioned previously, I think VM is particularly well-suited for the parallel 390 systems in ways MVS and Unix are not: it's a mature multiprocessor environment (unlike Unix), and runs well with small compute engines of the type planned for these processors. Most importantly, its applications make use of many virtual machines, or threads within multi-CPU virtual machines, and can therefore exploit many compute engines simply and naturally.

Personal/370, 390- an opportunity for IBM

IBM already has a wonderful opportunity to directly compete with workstation vendors, using an IBM-only technology that scales from desktop to ES/9000 without program change or change in data format, and is as open as any other software. Surprise, it's called VM!

The P/370, and now, the PC Server 300 Server/390, lets an IBM PC running OS/2 operate as a full, honest-to-goodness VM/ESA system with the compute power of a 4381, while it simultaneously runs other OS/2 applications. The P/370 was 370-mode only; the 390 is a fully compatible ESA processor that can run VM/ESA, MVS/ESA, or VSE/ESA (though VM will probably run best on it). This capability was recently extended to RISC/6000 AIX systems as well. Neither a toy nor a simulation, this processor is fully compatible with the real thing. The IBM Fellow's group at Kingston has done wonderful work producing this.

There are limitations with the product: it needs to be faster, and easier to purchase and configure. Nonetheless, this product is a rare chance for IBM to go head-to-head with its competitors in the workstation marketplace with the unique advantage that applications can be moved to the P/370 without conversion. No other vendor can do this - and IBM should capitalize on this special ability.

Unfortunately, IBM hasn't particularly marketed this highly attractive technology. Local branch people are either unaware of it or refuse to encourage it. It's only available via the OEM channel, or packaged as a PC Server, and not marketed for the individual desktop. Marketing people don't see any commission values from it and are afraid it will cost a mainframe sale. Let me make this clear: every P/370 that doesn't get sold is a new sale for Sun or HP. IBM must stop frittering away its last opportunities to market a 370/390 based workstation before it becomes irrelevant.

Managers under pressure to go distributed and get off the mainframe can use the P/370 to quickly and safely copy applications to distributed platforms, with the ability to run on the mainframe when needed for backup or especially large problems. Code easily moved to the P/370 can be easily moved back. Code painfully ported to C++ on Unix (mind you, overwhelmingly not AIX) is not coming back to IBM.

It's vital to IBM that people continue to code 370/390 software, and this is how to encourage it. Noted VM and industry expert Gabe Goldberg says that IBM should think of these boxes as seeds: plant a few and some of them might grow into ES/9000s.

The P/390 is essential to IBM. A key strength of IBM from System/360 days was the availability of scalable compatible performance - but this has now been preempted by Sun (the S in SPARC stands for Scalable). IBM can reclaim this ground by providing a desktop 370/390 that is compatible with the glass house, which also must be competitively priced with workstations and high-end PCs. DEC figured this out, and will use its Alpha and smaller VAX systems to regain profitability. IBM must do this also.

I hope this is now understood in important places within IBM, and we should expect to see increased development and marketing for this device. This is good for VM, for IBM, and for the customer - who will have unequalled flexibility and the widest range of options for compatible centralized and distributed computing. I urge you to push IBM to seize this chance before it slips away.

Flagship interactive system for mainframes

IBM eventually realized that VM/CMS is their best interactive system on 370/390 family systems. Real VM system workloads have thousands of users experiencing subsecond response times on the same 3090 or ES/9000 processor. With the corporate world still expending millions of dollars to provide TSO to their developers and users, there is considerable opportunity for CMS to save money and provide better service. The fact that CMS runs both on small and large hardware platforms means that VM can be used as the software base regardless of whether an institution prefers distributed or centralized computing.

IBM must keep VM on the desktop

IBM must not cede the desktop to other architectures. It's very important that VM stays on people's desks, not just on back-end boxes, because people will run as a server what they have on their desk. If the desktop is Sun Unix, then so is the server. Actually, Sun is now running into this problem, because 98% of desktops run Windows, and they're already seeing erosion of sales to NT servers. What's on the desk sells what's on the server.

Clients will configure this way because they need only learn one system and develop their code once, and because they can run their applications in both places. Sure, there will be cases where the mainframe is the big server in the sky for many workstations, but applications won't be written to run there. Nobody lives in the GCS environment, so its not surprising no applications are written for GCS.

VM/CMS obviously must compete with the workstation and PC lines in order to stay on desktops. Its competitive strengths of low cost-per-user, power, manageability, and reliability should be marketed, and the product enhanced to stay ahead or keep up with competing platforms.

It is obvious that IBM must enhance VM's interactive capabilities to let CMS applications exploit modern display technology. VM/CMS (and mainframes in general) will not be viable if the human interface is allowed to look stodgy and obsolete. A modern visual appearance is essential. Marriage to the obsolete 3270 makes VM and CMS look old and bad. Remember, Unix only had a TTY interface till recently, and look what a GUI did for it (transformed it from a horrid, unforgiving, cryptic failure in the commercial marketplace into the success it became).

IBM released a VM GUI for VM/ESA Version 2, which operates via TCP/IP and SNA. CMS users now can open and use multiple windows on the displays on their desks, use mice in addition to the keyboard, and can click on icons representing CMS objects: files, disks, directories, reader files, and so on. This is a very exciting direction, and one that is important to both VM's continued viability and to IBM. Coupled with VM's even more important role as a web server, this disarms the complaint that VM systems are chained to the old 3270 interface.

XEDIT has also been enhanced to work with the GUI environment. XEDIT should open a window when you invoke it or open a new file. Unfortunately, XEDIT has not been otherwise significantly enhanced for years: adding this support could make it a widely-recognized premiere editing environment again. Mansfield Software Group's KEDIT, an extended XEDIT workalike for PCs, has UNDO/REDO plus many other features that certainly could be available on XEDIT, even on 3270s. If Kevin Kearney can add these features, so can IBM.

A best-of-breed data editing and viewing tool is a key factor in system's success. I've seen people at my site FTP files from Unix to VM to use XEDIT instead of vi. It's very important that XEDIT's strengths not be abandoned. Workstation and PC editors are very nice, but lack many of XEDIT's strengths (expressive power, ease of use, ability to work with large files, and programmability with REXX).

VM must support open standard APIs

Among the other things needed are adoption of POSIX and OSF DCE (already in development, and looking very nice) transparent CMS multitasking, and a few easy tasks too: IBM should adopt (either buy or fund the authors at their universities) or partner with the developers of globally used tools like the World Wide Web, Gopher, Archie, and NNR at negligible cost. With very little expense, these can be kept current with developments in other platforms. Platforms that lack these services will appear primitive to people accustomed to them. At my company, availability of a World Wide Web server has led to a renaissance of interest and activity. We are able to unlock legacy data in the most trendy, hip way.

IBM must also start mentioning the DCE and POSIX capabilities for VM as often as they do for MVS, instead of keeping this emerging development unheralded. Frankly, I think VM's DCE and POSIX support will be much better than MVS's. CMS already has a tree-structured, distributed file system in SFS, so IBM is mapping the semantics of the byte-stream oriented file system onto it. MVS developers, poor things, have to emulate a tree-structured system on top of partitioned datasets in PDS/E. This must be challenging.

Reference to IEEE's POSIX standard, and the Open Software Foundation (OSF) Distributed Computing Environment (DCE) reminds me of another remark of Hal Lorin's: He says that two statements will be equally true in five years: Unix will be everywhere, and Unix will be dead. Unix will be dead because nobody will use the 25-year old kernel code it was based on; even systems continuing to call themselves Unix will be complete rewrites. Unix will be everywhere because many operating systems will support POSIX system calls (which started with Unix system calls and added many more) along with their own. Unix applications will be able to run on Unix, Windows/NT, MVS and VM systems, to name a few. Of course, CMS invented the concept of supporting foreign application interfaces, since it has emulated MVS and VSE system calls since OS/360 and DOS/360 days. CMS remains the operating system with the widest range of supported application interfaces - making it ideal for universal access to applications regardless of their original environment.

I happened across an interesting quote in Backoffice Magazine (May 1997). Columnist Joel Snyder, attacked for pro-NT, anti-UNIX prejudice, turns out to be a UNIX fan and expert with 17 years experience, and responded

My experience as a a Unix expert for many years is that readers were given a great deal of information that Unix bigots would keep from them -- that most good Unix platforms are as proprietary and hardware-bound as the other OSes, MVS, VM.

VM exploitation of advanced facilities

VM also allows access to advanced facilities, like dataspaces, the vector facility and so on, much more easily than MVS. My MVS brethren have a difficult time exploiting hiperbatch, which requires datasets be individually staged to and destaged from expanded storage, while VM derives tremendous performance benefits from minidisk cache without any administrative effort at all. MVS continues to have a terrible virtual storage constraint problem, 11 years after MVS/XA was announced. Continuous arguments are fought over whether the private area should be 8, 9, or 10 megabytes on our MVS/ESA systems, while our VM system provides large memory users virtual machines that are hundreds of megabytes in size, and many users run at 64MB or 128MB. Users with smaller requirements have virtual machines as small as 2MB on the same system - a trivial capability on our VM systems, impossible on MVS.

Our MVS people are coping with the difficulties of providing DB2 access across multiple CPUs. The current thinking is that we have to get big enough processors to run all the applications that access an individual database, and in some cases none exist yet! My understanding is that remote DB2 can be done, but with a great deal or work and overhead. Needless to say, SQL/DS applications on VM suffers from no such liability. I can't even think of when MVS will provide a distributed file system or CRR as a native feature. In VM, we added a second CPU and installed TSAF with very little effort, and routinely ran remote SQL/DS and SFS applications with cross-system data access and update. I compare this to the agony our sysadmins and DBAs go through to perform comparable functions on Unix or NT.

It's worth emphasizing that CMS's SFS includes the transparency, logical locking, and 2-phase commit and rollback needed for a production quality distributed file system, but not present in Unix. VM is almost unique in having a distributed file system with the facilities needed for robust applications, a fact I wish IBM would advertise. Unix NFS doesn't provide this. AFS (Andrew File System) has had little penetration, and DCE's DFS (Distributed File System) requires both a committment to DCE and a lot of management complexity.

[ Prior page | Next page | Top page ]