Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!cbatt!ucbvax!GRINNELL.MAILNET!McGuire_Ed
From: McGuire_Ed@GRINNELL.MAILNET.UUCP
Newsgroups: mod.computers.vax
Subject: (none)
Message-ID: <8703150638.AA28073@ucbvax.Berkeley.EDU>
Date: Sat, 14-Mar-87 00:38:00 EST
Article-I.D.: ucbvax.8703150638.AA28073
Posted: Sat Mar 14 00:38:00 1987
Date-Received: Sun, 15-Mar-87 13:49:56 EST
Sender: daemon@ucbvax.BERKELEY.EDU
Distribution: world
Organization: The ARPA Internet
Lines: 103
Approved: info-vax@sri-kl.arpa

> >A number of people have suggested that if the standard VMS command isn't
> >good enough, then we should write a command procedure to do it `better'.
> >I have some objections to this attitude.  They ultimately stem from the
> >academic environment, which it is my business to support.  In particular,
> >most of the users don't know how to write command procedures.
>
> (Aside: Isn't this some contradiction?)

Absolutely not.  The student users don't know how.  The academic programming
staff knows how, and has to decide whether it is responsible to heavily
customize the VMS environment.

> >1. If I write nifty COMs just for my own account, I find myself [. . .]
> >   forgetting how the vanilla environment behaves.
>
> Well, that reflects probably more of your idiosyncrasies than it is proof
> of the sufficiency of vanilla VMS.

That was a needlessly hostile remark.  It hurts when I make a contribution and
someone attacks me personally.

I never claimed that standard DCL was `sufficient.' My real opinion is that
standard DCL is 1) imperfect, and 2) the right thing for a university to
support, even though it is imperfect.

> >2. If I write nifty COMs for everyone, lots of bad things happen: [. . .]
>
> I agree for one special case: those silly procedures which claim to create
> a un*x environment. Like grep using SEARCH, only turning parameters around.
>
> Re: documentation: Any decent procedure should
> a) provide some in-built help and/or
> b) be accompanied by an entry in a help library.

The example you give is right on the mark.  I'm not fanatic about this: we do
provide a few front-end procedures, but they are carefully documented and
the DCL command to invoke them never replaces a standard DCL command.  The
one that comes to mind is a program that places an ACE on a file granting
someone else READ access.  We found the SET FILE/ACL command to be
prohibitively complicated for a novice.

> >3. COMs are more expensive than standard commands.  [. . .] Just for
> >illustration: Heaven help you if you replace the DIR command with a
> >front-end!
>
> That's fine for standard commands. But how do programs interface with the user?
> Every novice programmer starts hard-wiring file names into their programs.
> The user then has to rename the files to run it. Later, they discover the
> logical name. I can't expect my academic users to use commands like
> DEFINE/ASSIGN . I rather have a procedure which prompts the user for a file
> name, checks whether it exists and/or makes some assumptions about the file
> name and type, and comes up with a default name. Of course, all programs could
> be implemented using command line interface, but here you really need a lot of
> expertise and the execution time of a LOGIN.COM which does many SET COMMAND
> is prohibitive.

Wait a minute.  You're talking about program development here.  Anytime you
write a new program, you're perfectly right to implement the user interface
as you will.  Of course my remarks don't apply to this case.  I meant that
it was inappropriate to replace standard VMS commands with substitutes, and
I said so.

I agree that new programs should be developed using the DCL interface, and also
that it is complicated to do so.

By the way, we put user-written command definitions into the system DCLTABLES
rather than using SET COMMAND.  We preserve an unmodified DCLTABLES for safety
during software updates.  We don't change DEC commands in DCLTABLES.

> Have you tried to define the shifted function keys on your VT220 just by using
> DCL? Congratulations.

I don't see how this is relevant.  I'm sure I'm just missing the point.

> How do you lock your terminal from un-authorised use when you leave it?

I log off.

> How do you display all processes in your group/system, showing not only
> username and cpu-time, but also their login-time, currently executed image
> and possibly their real-life name?

Of course I've written a utility to do this.

> >4. DIGITAL is perfectly capable of improving the standard DCL environment,
> >   if we give them a clear message that it needs to be done.  Granted it takes
> >   time, but we end up with a better product, don't we?
> >   - `SET DEFAULT [nosuch]' could be modified to return a warning message for
> >     programmers, with a helpful message for novices such as `Directory does
> >     not exist--create it or choose another'
>
> ??? How does VMS distinguish between a novice and a programmer (and are these
> mutually exclusive?)

What I had in mind was a completion status whose severity is `informational' or
`warning,' and whose associated error text is `Directory does not exist--create
it or choose another.'

> Michael Bednarek (u3369429@murdu.oz.au)

Ed McGuire
Grinnell College
MCGUIRE@GRIN2.BITNET