A traditional method of packaging system facilities and user applications is the service virtual machine. We in VM have been thinking in terms of client/server computing long before the expression was kidnapped by PC and workstation vendors.
With varying degrees of effort, ranging from trivial to serious programming required, each of the listed event types can be intercepted and processed by normal applications programmers, and sometimes end users. Wonderful popular public-domain tools like IUCVTRAP, MSGTRAP, and RXSOCKET (written by the great tool-maker, Arty Ecock) and IBM's CMS Pipelines, WAKEUP and the Common Programming Interface for Communication (CPI-C), let REXX programmers intercept events and respond to them more easily than with other languages or platform.
No other platform allows such easy integration of event processing, usually at the CMS command or REXX level, for as many types of events and networking protocols. VM/CMS is unique in being able to communicate easily via RJE/NJE, Novell, SNA LU6.2 and TCP/IP protocols, without expensive, fragile, and inflexible middleware products. This is a strategic advantage of VM, with equal ease of program and client access to mainframe and open application interfaces.
VM/CMS offers more connectivity options, and makes them more programmable, than any other environment. This is true openness. In an increasingly heterogeneous computing and communications world, this is a strength that should be emphasized and exploited.
VM operator functions can be easily automated because the operator's console has full access to the rich toolset available to CMS: REXX, CMS Pipelines, and so on. This can't be done at the MVS or VSE console, because you can't run programs there. VM operators at my site set up their own simple EXECs, for example, to vary off ranges of devices or initialize tapes. Like our end-users, they are empowered to improve their own productivity. Similarly, the full-screen CMS HELP command lets operators look up the syntax of commands like XAUTOLOG or ATTACH without having to find the command reference, as with MVS. These prosaic capabilities markedly increase operator productivity, compared to MVS. The MVS market for automation products proves that it's builtin functions are inadequate.
The comparison with Unix and Windows applications is far more stark. Distributed systems have a great deal of difficulty presenting a single system image, or presenting a unified console or destination for system monitoring and automation. Read any computer trade magazine for articles on the difficulty of system management, and many ads for products purporting to solve the problems.
In initiatives I'm involved with for these systems, we're expending vast sums of money to provide the most fundamental system management functions. The rapidly burgeoning aftermarket (Tivoli, CA Unicenter, OpenVision, plus the many network management products) for system management and automation shows how difficult and expensive it is to construct reliable, automated systems in the distributed environment. I wonder how much network traffic in most intranets is merely SNMP traffic assuring monitoring servers that other servers are alive.
This is all very expensive. It's very common for the cost of the management software and staff to far exceed the cost of a server or workstations. This is definitely not a cost that the Unix (or PC) is cheaper crowd had reckoned with.
It's a great advantage that normal VM users can perform interprocess communication, create servers, and other advanced program tasks. In MVS, for the obvious contrast, it takes special system privileges to do any of these. You need a systems programmer to set up a started task, you need APF authorization to use cross-memory services for inter-process communications; it takes a guru to code a cross-memory POST (and if you blow it you can crash the system -- they run unprotected), and so on. VM applications need not run in a dangerous, unprotected state to do interesting things like handle events or create multiple threads of execution.
This affects program products from IBM and other vendors, too, since their applications often need system privileges to do interesting things. I was shocked to learn that many application products (4GLs, sort packages, report generators, and so on - not system functions like security, where system integration is obvious) require their own hooks into MVS, must be SMP-installed into MVS, and have caused system crashes! This isn't the fault of the local MVS staff - they're very skilled - it's a consequence of MVS design. VM avoids this complexity and risk entirely.
In like manner, consider how many facilities in Unix require root privileges, with not only the risk of crashing the system, but of compromising its integrity and security. It's just too easy to make a serious mistake in super-user mode, and almost everything interesting requires super-user mode. As I mentioned earlier, you also have to give out the root password to everybody that needs to run a root-mandatory function, or use suid scripts that temporarily assume root capabilities when run from a normal userid. Unfortunately, there are a number of well-known ways to acquire root because of suid programs. It's a very good way to penetrate Unix systems.
In contrast, VM permits flexible assignment of authority to multiple users, and provides granular distribution of system management functions to different privilege classes, so you can grant a userid some special powers without making it omnipotent. Best of all, VM lets general users do interesting and useful tasks without any sort of special authority.
Many of us know how valuable source code is for enhancing, fixing and understanding VM - all increasing VM's value to both customer and IBM. My site is hardly unique in using CP, CMS, RSCS, TCP/IP, and other components' source to enhance our system.
One of the worst things IBM ever did was introduce its OCO (object code only) policy, which retracted source code from customer access. This controversial policy reduced customer value of IBM systems, under the cloak of IBM's paternalism and asset protection. As disturbing as OCO has been, we are fortunate in the continued availability of source to most of VM, though not everywhere we'd like it. Worse, the fratricidal wars on this subject distracted IBM and its customers from more important issues, letting IBM's product line stagnate when faced by innovations in other areas.
VM compares very favorably to other operating systems in this regard. MVS is a well-known sad story in this area, with, until recently, exceptions like JES2 and JES3. CICS and IMS source code also have been withdrawn, causing many sites problems as they try to migrate to newer versions. This was painful in CICS, where IBM withdrew one of the application programmer interfaces, as well as a lot of control block information that is really needed in production. This is a demonstrable impediment to upgrades to new levels. Contrary to the claim that source code delays system conversions, I see ample evidence that source code makes system upgrades much easier and completed far sooner.
Unix's vaunted source code availability is much exaggerated. Commercial institutions have to pay outlandish license fees to obtain source code, and it's well-nigh impossible to get source code that matches the binary code you are running. Consequently, Unix is effectively OCO except at universities. In fact, a marketing rep from an unnamed Unix vendor to the NYC financial sector told me that not a single source license had been sold there. His attitude about local enhancements was also less than one would hope from an open systems vendor (Open, apparently meant Buy from Us in his lexicon). Now, perhaps that's the attitude of a sales rep (a special species); it may not necessarily reflect the attitude of the rest of his company.
Let me illustrate with a quote from Sun Server magazine, September 1997:
Sun Microsystems Inc. has announced that it will make the source code for its Solaris operating environment available virtually free of change -- for research and study purposes -- to the higher education community around the world.Speaking as somebody not working at a higher education institution, I say "thanks for nothing"! Especially, thanks for nothing when the source code would make it easier to deploy these systems for production use!
We should acknowledge that Sun took a leadership position encouraging computing based on openly available standards. Of course, this was with their own self-interest in mind, since this was the most direct way to attack their competition: all the installed base on PCs and mainframes! Openness is, more than anything else, a marketing slogan used to tout one's product line and chastise others as being closed or proprietary.
It's a true pleasure for me to be able to tell VM users Yes, we can make the system do that or I can tell you exactly how it works because I have the source, while MVS, Unix and NT promoters have to venture guesses.
This last point deserves great attention. Being able to determine exactly how something is working (or failing) averts misinterpretation of system interfaces and the resulting waste of application development time, reduces failures, and speeds debugging. I've observed a cultural difference here, too: we fix bugs when we find them either by ourselves or (preferably) by reporting them to IBM, but the Unix advocates seem to prefer to work around or (worse) depend on buggy behavior.
Unfortunately, I've seen this many times, and I've even heard of cases in which RFC standards were amended to conform to the bugs in a reference implementation on Unix, rather than the other way around. That's very sad. Microsoft advocates at my company (I'm not talking about Microsoft itself) go even further, aggressively insisting that Microsoft product idiosyncracies define what constitutes "the standard". I wish I was joking.
Source code continues to provide solutions on VM systems often though local modifications to IBM code. It is a point of absolute, literal reality at my site and other sites in the commercial and academic worlds, that source code is responsible for keeping applications on IBM mainframes under VM which otherwise would have moved to a computer made by someone else. I know of one case in which an IBM team convinced a bank's management that mods are bad; you shouldn't use them so well that they moved a working application from VM/CMS to Tandem! Not very good IBM marketing, I think. The good news is that, years later, part of the application still runs on modified VM code, adding value to this company's IBM investment.
In a world in which the word open has been debased to mean only I like it and serves only as an advertising slogan, IBM should promote awareness of the true openness it provides.
The whole OCO war is too long and tiresome to recap here, but let me make very sure that the reader understands that I and many others feel that this was a monumental blunder on IBM's part, and instigated more by emotion and arrogance than valid business plan. This policy was announced at the winter 1983 SHARE, along with the claim that IBM no longer needed customer-created solutions and creativity. How obviously foolish and arrogant this now looks a dozen years later. It was obviously foolish to many of IBM's staff and customers even then.
Even without the technical consequences, the irreplaceable loss of customer good-will can never be fully reclaimed. IBM fought with its customers (can anything be more foolish than to fight with your paying customers, who have recourse to other vendors?) and was distracted with this issue while their competition came up and ate their lunch.
OCO policy seems to be softening - much to IBM's credit. This trend needs to be accelerated, with the declassification of source code to modules that don't contain trade secret information. By this I mean full source distribution and update-level maintenance.
The PL/X compiler, for IBM's internal system programming language (previously named PL/S) should be licensed, just as Assembler H and HLASM (Higher Level Assembler) are. Anybody thinking that PL/X is a special technology providing competitive advantage to IBM is ignorant of the programming technology available on other platforms. Other operating systems are written in C or other HLLs. This was true when PL/S was first introduced, so there never was anything special about this. Keeping PL/S and its descendants inside IBM only prevented non-IBMers from writing code that would run on IBM equipment and generate revenue for IBM, and contributed to the rise of Unix and C. As Melinda Varian says in her history of VM: IBM has been forced to learn AT&T's system language because it refused to allow the world to learn its own.
PL/X has been a trailing edge technology for a long time, largely because it was never made public. A PL/X revenue stream would have justified its enhancement, making it a more useful tool for IBMers, and providing encouragement for developers coding on 370/390 platforms. PL/X should be made available to IBM customers now (at a reasonable price) so we can salvage what is still left.
It's not just PL/X, of course. The decrease in importance of PL/I, formerly a key IBM technology, can be at least partially attributed to the lack of health of PL/X. It's not just IBM's operating system developers that have moved from PL/something to C or C++, it's also their customer base. A robust system programming capability in PL/I, or in a PL/I dialect available to PL/I developers, just as is available to C programmers, would have made PL/I much more vital.
What would we have if source had been more generally available? Customers use source code for much more than mods: we read source code to better understand the system far more than we write code to change it. We also use source code to debug systems and our applications. However, let me mention enhancements to a single product that surely would have been in VM or VM-based products had source code been available in the field:
We would definitely have had a fully SFS-compatible OfficeVision years before it came "officially". This would have enabled savings in disk space, and increased capability for space management and file sharing for OV users - and helped reduce cost of ownership to help keep VM and S/390 competitive. IBM neglected OfficeVision/VM (or PROFS, as most people called it) so badly for so long that it ran the product into the ground. This neglect has ceded e-mail (where VM and IBM had the industry dominating position) to other vendors. IBM could have easily made OV an engine for modern groupware applications and added a good user interface or a POP3 server capability. Opportunities lost forever. I simply cannot understand why this once-dominant product was discarded, along with it's massive mindshare and revenue stream.
I must note that OV is totally irrelevant at my company, despite some residual use, as we've moved to other products (whose owners took the trouble to enhance and market them). We rolled out MS Exchange at great cost, and that will be the end of OV at this company (fortunately, that's not the reason we obtained VM...)
Just consider some functions written in the field, in VM itself, where users had access to the source code: PER command for debugging, CP page migration and block paging in VM/370, the Cornell scheduler written by Bob Cowles that provides real guest-CP interaction, RSCS distributed authorization, alternate nucleus years before IBM's, dynamically changeable system logos, the AUTOLOG command, shadow table management, padded shells (before the CONCEAL option, and more rigorous), group userids, CMS file read-ahead, and other functions, all first appeared as user code before similar functions appeared in IBM code. Some functions (like Bob Cowles' scheduler and guest handshaking) never did make it.
The following were done at Merrill Lynch: multivolume CMS tape support before SP4 CMS - and supporting user exits in REXX instead of assembler, SET MORE/SET HOLDING (I did in VM/SP1, now finally in VM/ESA a decade later), SET SECUSER (we had since 1985), XA LDEV relief (my version before VM/XA APAR), XA alternate nucleus (based on code from Teachers Insurance) VSAM objects on filemodes R and T, and a few others well before similar function appeared in IBM code. We use a SUBCOM interface that lets TCP/IP FTP functions be programmed in REXX, and added early SFS support for FTP as well - both features we need and can provide because of source code availability (IBM has since delivered SFS support for FTP, but we're still waiting for NFS support). We also enhanced TCP/IP's network database (NDB) for workstation access to our SQL/DS databases.
The point isn't that my site or others are particularly smart or wonderful or that IBM isn't - the point is that real users in the field came up with solutions they needed before IBM was ready to or saw a business case. Making this possible increases the value of IBM's product line and makes it more competitive.
There's some good news: The recent advent of powerful, flexible World Wide Web servers for VM opened up new opportunities for VM systems, spawning more interest in VM than I've seen for quite some time. It would have been nice if IBM did the obvious smart thing and fund or enhance Rick Troth's work several years ago, but Beyond Software (now Neon Systems), Velocity Software, Information Builders, and Sterling Software saw the opportunity implied by VM web servers and have released products that increasing VM's value.
[ Prior page | Next page | Top page ]