I always tell the new users that HELP is the single most important
command in VM. The problem with some commands is that I have to use HELP
almost every time I use them.
I remember once, I don't remember whether it was in a discussion of SFS
commands or those of VMSES, but it could easily been the MODIFY USER
command, drawing a parallel between ordinary English and the syntax of a
particular command that went like this:
Suppose you are having a large family dinner, say for a family reunion
or holiday. You would like some potatoes, but they are at the opposite
end of the table. In normal conversation you would say, "Please pass the
potatoes." If you were to make the same request using the suggested
syntax, the request would be, "For the potatoes please pass." My
conclusion was that the suggested syntax was something that only a
mother camel could love. There is certainly nothing gained in elegance,
conciseness, preciseness or clarity by phrasing it that way.
I realize that SFS and VMSES have been in use too long for the command
syntax to change. It has been years since I read Strunk and White's
"Elements of Style", but that book ought to be made required reading for
anyone who is going to create a command syntax or commands for others to
use. The principles appropriate for clear communication do apply.
Analyzing the MODIFY command to determine what is meaningful or needed
would go something like this:
MODIFY - Needed to convey the action to be taken.
USER - There is only one form of MODIFY, so this is a
useless word. Furthermore, it is misleading.
blocks - Needed.
FOR - Not required, simply a place holder and not a
very good one at that.
filespaceid - Required, and not necessarily a userid.
The remainder of the command can be left out of the discussion as it is
optional information.
This leaves us with a command consisting of the three elements MODIFY,
blocks, and filespaceid. The next question is, "Does the order matter?"
I would submit that it probably does, that the order imparts meaning.
For example, you are modifying the parameters of the filespace by
allocating or adding blocks to it, not modifying a number that
represents a subset of blocks in a file pool. The most meaningful order
is to have the thing being modified follow the word "modify". That
would give us a command that looks like this: "MODIFY filespaceid
blocks". If you feel that a noise word is needed, then perhaps something
like "MODIFY filespaceid BY blocks"; however, the noise word, being
nothing but noise, should be optional.
Regards,
Richard Schuh
> -----Original Message-----
> From: The IBM z/VM Operating System
> [mailto:[EMAIL PROTECTED] On Behalf Of Alan Altmark
> Sent: Monday, November 24, 2008 7:33 PM
> To: IBMVM@LISTSERV.UARK.EDU
> Subject: Re: new VSMDCSS in z/VM 5.4
>
> On Monday, 11/24/2008 at 07:13 EST, "Schuh, Richard" <[EMAIL PROTECTED]>
> wrote:
> > Yes, and it would be nice if there were easy to use and remember
> > administration and user tools. The syntax of some of the
> commands is
> > not the most natural that I have ever seen. "MODIFY USER nnn FOR
> > userid" is a good example. It reads like the userid is
> "nnn". I do not
> > know where anyone got the idea that the "verb predicate for
> subject"
> > syntax was good or natural. Is there any spoken language that uses
> > this type of syntax? (Where is that mother camel?) And this
> is perhaps
> > the simplest case.
>
> We found over the Ages Past that beautiful syntax (words and
> music by Stephen Foster) is in the eye of the beholder. I
> remember when we were having arguments over SFS syntax (I
> think this was before the CMS Windows syntax debacle had
> fully hit the fan), there was a lot of knashing of teeth.
> Our conclusion: You can please some of the people some of
> the time if you're lucky. Since you can redesign the syntax
> until the cows come home, we picked a syntax and moved on.
>
> If you can't remember, try HELP SFSADMIN MODIFY. If you
> issue the command a lot and still can't remember, put it in
> an exec that implements a syntax you're comfortable with.
>
> Alan Altmark
> z/VM Development
> IBM Endicott
>
