[FreeVMS] Re: Command and qualifier validation


Subject: [FreeVMS] Re: Command and qualifier validation
JayPedHskr@aol.com
Date: Fri Jan 02 2004 - 08:43:35 CET


In a message dated 1/1/2004 2:39:13 PM Central Standard Time, stan@stanq.com
writes:
Because parameters specify information that cannot be known by the
system. The user's input is taken verbatim, because the user is
supposed to know what needs to be done.

Qualifiers, on the other hand, come from a small, known, constant
set. Only checking the first few letters allow users to abbreviate
the qualifiers.
I am not suggesting that we disallow abbreviation of command names or
qualifiers. An unambiguous abbreviation should be allowed as DCL has always allowed
it.

What I am suggesting; is that if more than 4 characters are given in a
command name or qualifier ... that they be validated. DCL does NOT perform such a
validation (never has, at least since VMS 2.0 or so when I started using VMS).

That is what I tried to show in those examples.

  SHOWDKDKD ... ignores DKDKD after SHOW

  /FILEDKDKD ... ignores DKDD after FILE

In my opinion; that should be flagged as an error.

If you would like to say "SHO DEV/FIL" ... it should be supported, just as
DCL supports it.

The oddity was that saying 'SHOWDKD MEMODKD" ... was flagged as an error
because characters after MEMO (short for MEMORY) ... did not match the definitions.

I guarantee DCL understands that the parameter is MEMORY. It is defined in
the CLD for the SHOW command. It is not some program-specific parsing, it is
standard DCL parsing. In my opinion, there should be no difference in the
handling of the command SHOW, the parameter MEMORY and the qualifier FILES.
However, there is a difference. Only the parameter is forced to match exactly ...
the others ignore characters after position 4.

I think the 4-character checking cutoff was some optimization that made sense
in 1978 and not now.

-Jay

-- 
Liste de diffusion FreeVMS
Pour se désinscrire : mailto:freevms-request@ml.free.fr?subject=unsubscribe



This archive was generated by hypermail 2b25 : Fri Jan 02 2004 - 08:43:48 CET