As mentioned previously, even honest-to-goodness end-users are capable of building their own applications under CMS. User enablement is a key advantage of VM that we should encourage.
IBM can increase this advantage by continuing to release its wonderful set of internal tools to the VM public. These tools, include full-screen and panel builders, debuggers for REXX and other languages, file utilities, and many more valuable programs. By releasing them, perhaps with limited support, IBM can enrich the tool kit available to all VM programmers. It's important that these tools be universally available so programs exploiting them can be freely distributed among sites. Otherwise, developers are forced to avoid useful tools because the sites they send code to may not have them. This is especially an impediment to the vendors that create value for the VM marketplace.
CMS Pipelines definitely places CMS far ahead of its competitors. I regularly use Solaris, MS-DOS and Windows NT, (and sometimes OS/2 and AIX) and am frustrated at things I cannot do because CMS Pipelines is unavailable. I've heard exactly the same comment from my users that also work on Unix. They miss CMS Pipelines and find the original pipe implementation a very inadequate substitute. It takes them days to do what takes only minutes on CMS, because things you can do in a few lines of code with CMS Pipelines take dozens or hundreds of lines without it. Pipelines is the best tool available for for everything from general purpose data crunching, event processing, or writing TCP/IP servers!
The most important thing IBM can do to enhance VM/CMS
is to continue to fund Pipelines' inventor
John Hartmann of IBM Denmark, and his work extending CMS Pipelines.
His accomplishments provide the technology
that is the single enabling factor for new developments at many sites.
For starters, the wonderful Webshare World Wide Web server
by Rick Troth, and the commercial version EnterpriseWeb
from Neon Systems, Inc (acquired from its first owners,
Beyond Software, Inc.) are made possible by CMS Pipelines (and
also REXX Sockets by Arty Ecock of
City University of New York).
Programmers want to program on the system that makes their job easiest and most pleasant, and where they can get the job done fastest. IS managers may not care if the programming environment is pleasant, but they do want results, and therefore, productivity. Anything that enriches the set of tools available to all VM programmers makes VM more competitive.
VM's ability to deliver results faster than other platforms is essential to its survival. Just yesterday (I'm writing this paragraph in March, 1996) I was at a meeting where we were discussing whether to keep a particular function (a World Wide Web application) on VM. The application manager said to a staff member who wanted to move work to a PC: No, you don't understand. Jeff has this awesome code on VM, and he can he can knock out solutions much faster than we can (on NT using C). That's as explicit a statement of this value as I have ever seen. Now, if we moved the function off VM, the suggested replacement would be a socket application connecting NT and VM - and of course it would use REXX, CMS Pipelines, and probably REXX Sockets, too!
RAD is a buzzword now in the software engineering world. CMS has always encouraged quick application development by removing impediments (like JCL) and by making available a wide range of tools. CMS lets its users concentrate on their applications, not on the system. Compared to most other systems, VM users and developers have little need to concentrate on minutia like dataset allocations and blocksize, or artificial constraints like a 16M line (or on PCs, the 640K line or problems converting between 16 and 32-bit applications. Why should a 32-bit operating system be considered an innovation?) It's simply easier to quickly knock out applications on CMS than in other environments.
I have two quick stories that illustrate the power of CMS, as well as some cultural differences. I implemented a full-screen phone directory system on VM using a few of these tools. The experience was illustrative of the difference in systems: it took me a good part of two days to put up a full-screen applications with search capabilities and a number of options. It took an MVS system programmer, a very sharp guy, about a month, and his version had less function (he first tried to use ISPF table commands, and gave up because it was so darn slow). Finally, the Unix people just took the file I gave them and stuck it in a directory without any tool at all. By gosh, if you want to look up a person's phone number you should use grep like a REAL programmer! Later down the road, it only took me about an hour to convert my nice XMENU, 3270 application to an even nicer World Wide Web application, now used throughout my company. Combined with a PIPE stage that reads data from our MVS DB2 Human Resources database, this web page is now my company's official electronic directory, plus its first working example of a Web-enabled DB2 application.
Another example came about when we got our cc:Mail and OfficeVision systems talking to one another. The cc&gml.Mail people had a nice nickname convention and we didn't, so we agreed to standardize on theirs (ours was very informal: I was the first Jeff to be registered, hence I owned that nickname. Not a good practice). One of the guys in the VM group, Daniel Friedman, wrote a quick REXX program to convert all our nicknames into the new standard format; the whole thing was done the same day. It turns out that the other guys never had actually implemented their standard, but were going to write an object-oriented C++ program (I'm not kidding) to do the same thing. Since O-O programming is so great this had to be a Good Thing. Two months later they still hadn't finished, so we just adapted Daniel's program and ran it on our copy of their directory.
With the advent of VM-based World Wide Web services, I'm now seeing novice VM programmers (for the first time in quite a while) generating sophisticated, attractive applications with very short learning times - a testament to both the power and ease of use of CMS programming functions. They're programming using REXX and CMS Pipelines, because that nets them fast results they cannot get anywhere as easily on other platforms.
We see examples like this with MVS, PCs and Unix all the time. When we have to develop something to cooperate with one of these other platforms, we get our part done much faster and with less fuss. I like to think that the reason is that we VMers are so much smarter and better looking than the others, but it's really because our tools are just so much better.
One problem with competing systems is that they make it much more difficult to reliably separate program development from production. Most sites have a critical production environment that simply must be protected from accidental or deliberate damage.
MVS for example, provides only one namespace of files, so there's really no way to test JCL with the same dataset names that will be used in production without impacting production. It's easy to accidentally mess up production simply by allocating a dataset with DISP=OLD (exclusive access) even without opening the file. Common virtual storage has to be tuned for both production applications and for development, which have quite different module and private storage area requirements. It's no wonder that most large MVS sites feel obligated to keep production and test on separate systems. Another reason, of course, is that it's hard to fit production on a system that runs TSO.
Of course, MVS's problems are dwarfed by those in Unix, where there is a single root userid and password (which you must share, making security impossible) for any administrators doing anything remotely interesting) and a single root filesystem.
It's just impossible to meaningfully separate Unix functions for isolation. When you look at simple things like file-locking, you see that the recommended method is to use advisory locking, which may be ignored by any non-compliant application.
The only way to reliably separate test from production, or application from application, is to add yet another machine, to the ever-growing crop of servers that have to be funded, installed, and monitored. Unix system practice invariably gets a separate box, if for no better reason than the expectation that excessive resource consumption by one application (especially a CPU loop or "memory leak") will break any application running along side it.
We have about 900 Unix servers in one building alone. Do you really think we're getting economy of scale and actually using the aggregate CPU power of these machines? The costs are staggering.
A similar problem occurs in each dialect of Windows, where (for example) every install process places DLL files in the same system directory that really should belong to Windows. Even the trade press has noticed how multiple products trash one another by overlaying the same file names in the Windows system DLL directory. Sad, very sad. You certainly wouldn't want to share NT boxes for multiple applications, for the same reasons as Unix.
The virtual machine paradigm provides safety. It's easy to separate test and production in parallel, non-interfering virtual machines. Users can damage themselves (it's your gun, your bullet, your foot) (With Unix, I like to say you aim a little higher) it's much harder to hurt others. The reasonable defaults and checking performed by CMS commands also make it less likely that you will even damage yourself, compared to other systems.
[ Prior page | Next page | Top page ]