Re: How did AIX beat out i5/OS was: IBM tech support for BCS

UNIX was originally written for DEC PDP machines that used ASR-33 teletypes. Does anyone remember those? If so, you might recall that it was all but impossible to "touch-type" on those keyboards; as the keys were very hard to press. So you had to resort to "two-finger" typing. All output was UPPERCASE ONLY. So, the "design decision" for UNIX was to keep the command line interface as terse as possible, to reduce the amount of typing on those difficult terminals.

Unfortunately, as those early terminals were replaced with "glass teletypes" and newer and better terminals, this fundamental user interface design decision was never re-visited. And so, UNIX is still "stuck" with those cryptic commands and -x -y -z arguments.

Note that UNIX was also designed to allow you to write your own "shell" (the "CLI" or "command line interface). This is similar to how IBM's TSO allows you to write your own Terminal Monitor Program (TMP), although I have never heard of anyone who actually ever really did that (a daunting task).

In UNIX, you already have the original Bourne shell, the Korn shell, and BASH, the "Born-Again shell", among others. It should be possible to write a UNIX shell that provides much the same kind of command interface that OS/400 or i5/OS provides. (QSHELL for i5/OS is yet another "shell". And PASE has its shell.)

One problem is, what kind of terminals would you support? Absent a "block-mode" terminal like a 3270 or 5250, it is much more difficult to design a full-screen interface for prompting, etc. -- when you have so many different terminals out there, each supporting different features, etc. UNIX tries to cater for the many different terminals with TERMCAP and the CURSES library, etc., but these are compromises, at best.

An important feature of the OS/400 *CMD design is the idea that you have "command definition" source that is compiled into a representation (object) that is used at runtime, to identify the keywords, values, etc. for each command, and the name of the program to call. This approach could be used for UNIX commands. The main difference would be, instead of just specifying the program to call, you would be specifying the name of the underlying command to invoke, and each of the different keyword(value) pairs would generate the appropriate arguments, e.g. "-x". Then, if the UNIX command ever changed or added new parameters, you would simply edit the command definition source file and recompile it to create the command definition object (which would of necessity be just another binary file on UNIX systems, perhaps with a file type of ".CDO" for command definition object?).

(I proposed exactly this approach to IBM for AIX around 1995, but the idea apparently "fell on deaf ears.")

Someone could still build such an interface for UNIX, and try to "sell it" to AIX customers, to LINUX users, to HP-UX users, Solaris customers, etc. -- but, in today's world, where the browser or some other GUI interface seems to be the popular choice, would such a product stand a chance to gain any traction?