Path: utzoo!utgpu!water!watmath!clyde!rutgers!sunybcs!bingvaxu!leah!uwmcsd1!lakesys!gryphon!crash!jeh
From: jeh@crash.cts.com (Jamie Hanrahan)
Newsgroups: comp.os.vms
Subject: Re: VERB program (was: VMS_SECURITY)
Summary: Please don't change DEC-defined defaults in SYS$LIBRARY:DCLTABLES!
Keywords: system management support nightmare
Message-ID: <2159@crash.cts.com>
Date: 18 Dec 87 00:08:24 GMT
References:  <8712170453.AA25530@ucbvax.Berkeley.EDU>
Reply-To: jeh@crash.CTS.COM (Jamie Hanrahan)
Organization: CMKRNL Press, San Diego, CA
Lines: 60

In article <8712170453.AA25530@ucbvax.Berkeley.EDU> KHDCS@ASUACAD.BITNET (Derwin Skipp) writes:
>Following is the BLURB.TXT for the VERB program off the DECUS VAX SPR85
>tape. This is probably what you are looking for...
> ...This program
>is a must if you need to change verb definitions, or if you just hate the
>DEC defaults (getting tired of HELP/PAGE, or LINK creating maps when
>executed from a batch job?).

Excuse me, but this pushes one of my buttons... It is perfectly fine to use
tools like VERB to build your own dcl tables, but please do NOT change the
DEC-defined commands in SYS$LIBRARY:DCLTABLES.EXE!  

A new user logging into your [I'm speaking to system managers here] system 
should see a system that looks exactly like what the VMS doc set describes 
(except for bugs in VMS and/or the manuals :-), and of course with the addition 
of whatever layered products you've installed).  No redefined DCL commands, 
whether via mods to DCLTABLES or symbol definitions; no `extra' commands
like sd or finger or etc.; no nothing!  Resist the urge to do favors `for'
your users by defining new commands that will make things `easier' for them.

What you are in fact doing is (a) making life difficult for them when they
go to other machines; (b) risking havoc with VMSINSTAL (and lots of other
DEC-suppled command procedures); (c) making your user education job bigger;
(d) taking on support hassles when things change in the next major release
of VMS... 

Sure, some extensions to the system are nice to provide to folks.  What
we do here is to have a file called USERLOGIN.COM that sits in a public-
readable `utilities' directory.  The system-wide SYLOGIN.COM only displays
notices, etc; the standard LOGIN.COM that we supply to new users consists
of one line:

	$ !@SYS_UTIL:USERLOGIN	! uncomment to get site-specific ext's to DCL

Notice the leading "!".  We also supply them with a document that lists
all the layered products and public-domain software and etc. that's on the
system, and points them to information about same if it's too lengthy to
put in the document.  We tell them that if they want to invoke USERLOGIN
from their LOGIN.COM, they can; they can also copy it into their own
directory and delete what they don't like, etc.  This way users have 
their choice; they can have the vanilla-flavored system, or `our' system,
or `their' system, or anything in between.  The point is that no changes
to the vanilla environment are forced on them.  In particular, no changes
are *invisibly* forced on them.  (Ever known system managers who set
SYLOGIN.COM to execute-only?  Gawd!  If I'm trusted to log in, I ought
to be able to look at what the system manager is doing `for' my working
environment!)

Sure, documenting all that stuff is a hassle.  But it helps you in two ways.
First, it aids the user in understanding their working environment.
Second, if you make a rule that you won't install things in USERLOGIN
without documenting them, you're less likely to put in a bunch of frivolous
stuff... :-)

Of course I'm not talking about application-only users who should never see
a DCL prompt, being locked into menus.  But if the user ever sees a DCL
prompt, they have a right to expect what the orange books tell them about
the DCL environment to be true, unless *they* have chosen otherwise.  

(P.S. -- Don't change the DCL prompt `for' them, either...)