On 2014-07-25, at 08:40, John Gilmore wrote: > We disagree, sharply. The abbreviation of long keyword/set element > values using the notion of a case-independent disambiguating > truncation is 1) convenient and 2) easy to teach in the sense that > programmers and others come to understand it quickly. > And here, I take Fred's side. As a novice VM/CMS user, I recoil from EXECs or, worse, forum submissions intended as pedagogic that use single-letter abbreviations of commands and elide prepositons where the result is unambiguous.
And as the CMS vocabulary has grown, traditional abbreviations have become ambiguous, but CMS maintains an abbreviations table, manually maintained, with a minimum length for each. And the single-character non-prefix abbreviations of MVS/JES operator commands are as offensive as the 2-character state codes. (There also is, or was, a convention of 2-digit numeric state codes. These matched the state names in collating sequence. I wonder how the scheme was upset by Alaska and Hawaii?) > The > > start, stop, status > > problem that Fred raises is highly artificial. It is indeed a straw > man. If a keyword set already contains 'start' and 'stop' there in > no need to add 'status' to it. One can add another keyword > value---'query', 'condition', 'info', or the like---instead. > Ugh. I suspect the UNIX command set was somewhat influenced by such practice. -- gil
