CMS Productivity Advantage
Lest we forget, CMS command syntax is still much better for real users than the command language environments in TSO, MVS batch, Unix, MS-DOS, and so on. This inspired the choice of the teddy bear as the official VM/CMS mascot, because of VM's warm, cuddly nature
Only the GUI environments challenge CMS in this area, and with a serious loss in programmability. A modern VM screen interface would let CMS leap-frog its competitors in ease of use and expressive power. Fortunately, a CMS GUI is available for VM/ESA Version 2, with clients on AIX, OS/2, and Windows (but I need one on Solaris, too!)
The ultimate crummy command language, (with the exception of Unix) is MVS JCL. It's worth discussing this at some length, not only because there's perverse enjoyment in beating a dead horse, but because we should be able to express to our peers and management how inferior MVS is to VM/CMS in this area. JCL is so familiar to mainstream IBM customers that they accept its deficiencies as the way things are. It's valuable to highlight this to emphasize how CMS provides better productivity and power.
JCL is so bad that it's traditional for users of non-IBM systems to make fun of IBM based on JCL alone; insult JCL amply earns. This is not a trivial point: obscene //GARBAGE syntax is how humans are expected to instruct their MVS systems. It is an incredible barrier to productivity that users of VM and other civilized systems don't face. I like to say that God never intended for there to be three commas in a row. The fact that VM audiences get this joke and laugh at it testifies to VMer's multi-system literacy (as well as VMers good taste in humor). For readers that don't know JCL: there are a number of places in JCL where you have to insert adjacent commas to indicate omitted positional parameters.
JCL was designed when it was expected that computer applications were batch jobs that would be started infrequently and would run for hours. It didn't matter that the syntax was ugly and error prone, and could only be coded by specially-trained technicians, since not much of it was going to be needed, and since computers were obviously only going to be used by white-coated technicians. Unix has the same problem - designed in the early 1970's by brilliant computer scientists for other computer scientists.
JCL is an example of the second system syndrome cited in Brooks' The Mythical Man-Month: designers building their second system add every feature, option (and wart) they didn't have time for the first time around. In this case, the first system was the 7090 $IBSYS system. JCL is $IBSYS control language extended to its hyperbolic, self-parodying conclusion. Actually, we shouldn't blame the JCL designers: they developed a command language for the environment they expected it to serve. We should blame IBM for never having had the nerve to confront the issue and gracefully phase JCL out once its deficiencies became obvious. We should certainly chastise the designers of TSO, for blessing the industry by bringing JCL to the terminal.
TSO is unusable without ISPF, and isn't that great with it. Most TSO users can't use fundamental TSO commands: how many can properly use ALLOCATE and ATTRIB to create a file (oops, I mean dataset). TSO users have to be hidden from TSO. One never saw lots of people using TSO, except for developer and datacenter staffs.
It's not just JCL, but the incredible detail it forces programmers to specify. During an internal VM class at my company, an operations manager asked Why are there so few storage problems on VM? MVS jobs frequently ABEND because a file required more disk space than the JCL specified (or the space was not available within a fixed number of contiguous areas). MVS programmers must estimate the size of each file, and code the estimate in the SPACE= parameter in each file's DD (data definition) statement. They get no points for getting the estimate right, but get lots of attention for getting it wrong! VMers have the advantage of not having to pre-guess file sizes, nor do we have to waste time on nonsense like PDS compression or optimal block sizes. Neither, of course do programmers on PCs and Unix. PDS/E and SMS address some of these issues, but incompatibly and 20 years late.
Worst of all, if you develop an MVS application using TSO, you might write the control portion in CLIST or REXX, but you have to convert it all to JCL, of all things, when you put it in production.
Unix is famous for its guru-mandatory syntax. While Unix is wonderfully expressive for experts, it is remarkably cryptic. Unix command names were inspired by 10 character per second teletypes (when TTYs were really Teletype 33s, and brevity was valued above all other virtues) and are uniquely non-mnemonic: cat to type a file, mv to rename a file, for example.
Unix commands are also dangerous: cp and mv quietly overwrite existing files (as do many other programs) rm * happily removes all your files, tar overwrites like named files, and so on, unless you take care to alias these commands to turn off their default, dangerous behavior (or do crazy things like generate a funny filename like -i in each directory so * will expand to include the -i flag that asks the user to confirm removal of each file). If you're lucky, I suppose, you'll have too many files in the target directory, and the expansion of the rm * will fail. You see, the shell, not the application, is responsible for expanding wild-cards, and if the number of files in the current directory would cause the resulting string to exceed a particular buffer, the whole thing fails. Oh, and guess what happens when you want to use * in a calculator program invoked from the command line. You get the idea.
There are so many things that just drive you nuts about Unix. For instance, the standard way to indicate options to a command is to have single-character flags after the command name and before any other operands. Not much opportunity for readability and mnemonic value here. For example, the command ls -l lists your directory in long format, with file information details. So, you have a hyphen, otherwise called a minus sign to turn options on. Counterintuitive, no? So, when you have an option to turn something off, you use the plus sign! If there were a Unix command to order a burger, with ketchup but hold the fries, it would look like (guessing a cryptic word for the verb for true Unix flavor)
bgr -k +f my.burger
I really don't have the time, space, or interest to go into all the misfeatures in Unix's command line interface, let alone the silly things that it forces users and programmers to know and do (can you accurately describe the rules for quoted strings and escapes in the different types of shells, based on whether you use an apostrophe or double-quote character? Too few can.) It's really an impediment to getting the job done. If you want to learn more, I strongly recommend the very funny (and accurate) The Unix-Haters Handbook (Garfinkel, Weise, Strassman; IDG books) that points out some of Unix's egregious sins.
Part of Unix's appeal was that it was so difficult to use that it was a mark of prestige to be have any results - it set one apart from the unwashed masses. The command shell is very powerful once you've mastered it, but it's very dangerous and punishes failure with loss of data and time.
It is no accident that Unix was a failure in the commercial marketplace until 1989 or so, 15 years after the CACM paper describing it. Unix required the GUI systems then becoming available in order to make it remotely acceptable for non-computer scientists. Windowed GUIs are nice, but the sad fact is that the commands you enter in the pretty windows are the same ugly, cryptic teletype interface commands that have existed all along. As stated in The Economist, Unix is not vastly more user-friendly than Chinese ideograms The infatuated trade-press and gurus have skipped over this insignificant detail in their headlong rush to sell you Unix.
CMS Productivity Advantage
Enough about them. CMS's native command language is very easy to
learn and use, and is enhanced by the availability of REXX,
invented by IBM's Michael F. Cowlishaw. Even some
of the Unix users at my company agree that REXX is better than the
shell language they use (those who have also used CMS agree; those who
have only used Unix don't). Even the relatively new perl
bears the same relationship to REXX that Unix bears to CMS: lots of
expressive power, but not suitable for non-expert users.
Note how REXX has been ported from CMS to TSO, AS/400, OS/2, MS-DOS, Novell, VAX, Amiga, Macintosh, Tandem, and Unix. No other shell language has had such enthusiastic acceptance outside its original system. OpenEdition MVS and VM will provide POSIX-compliant Unix commands and shell, but this is a concession to the reality of Unix's wide acceptance, and intended to provide portability for Unix program and skills, and not provide improved productivity relative to native facilities
People spend most of their time in an interactive system manipulating files (see Pat Ryall's Why CMS? paper for an excellent discussion). XEDIT, REXX, CMS's wildcard capabilities, FLIST/FILELIST, and now CMS Pipelines provide tremendous capability for manipulating data in a natural manner.
The advantages of XEDIT as a universal, excellent CMS text editor can't be understated. TSO users at my place gape enviously at what XEDIT can do; the Unix users all grudgingly use vi not because they like it -- they don't -- but because it's there (it's the only editor guaranteed to be installed on all Unix systems. It's about the worst editor I've ever seen). The real hackers tell you to use emacs, but it suffers greatly by comparison to XEDIT, especially with regard to ease of use for non-experts. I've seen users upload files to VM from Unix so they could edit it using XEDIT. I especially noticed this when a user edited a 100MB Sybase error log file on VM. He just laughed when I asked him why he didn't edit it on his SPARC workstation!
CMS is a proven platform for user enablement. It still surprises me how productive CMS end-users are: I see program traders and investment bankers creating their own applications, using fundamental CMS facilities and a suite of products. CMS empowers users to build systems for themselves in ways not possible with harder-to-use systems.
None of the advocates for the systems VM competes with at my firm contend that MVS, Unix, or MS-DOS let business principals form their own solutions. With VM, there's only a short distance to travel from formulating a problem to solving it, using a rich toolset and a natural form of expression. CMS Pipelines and REXX make a great deal of power available to the user, with much more ease and accessability than the corresponding (and less effective) tools in Unix and Windows. I see novices and business principals using REXX and Pipes, but not using C++, ksh, perl, Visual Basic, or Java. I actually expect successes in this area with Visual Basic, but it is highly proprietary, limited to Microsoft operating system environments, and it is just not as good as REXX.
This is a tremendous competitive advantage for VM, since it reduces personnel costs, and removes the layer of communication needed when an analyst has to explain his or her requirements to a programmer.
[ Prior page | Next page | Top page ]