jeh@crash.cts.com (Jamie Hanrahan) (12/18/87)
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...)
rrk@byuvax.bitnet (12/20/87)
I have to give a very solid vote FOR the note by Jamie Hanrahan. The only thing more agravating than having to work on two systems which managers have decided to "rearrange" just to suit their own taste, is a system manager (the likes of which I've encountered and yould have liked to shoot every day of every month I used a system managed by him) whose tastes seemed to change daily. Changing the names of commands, queues, and the defaults taken by qualifiers (have you ever spawned and had a system manager helpfully make the /NOWAIT qualifier default?). What users do for themselves in making commands more convenient is fine. They made the definitions themselves and can even port them or learn to live without them. But a system manager's only function in defining the DCL environment should be to add new things that THE USER CANNOT GET IN ANY OTHER WAY. Defining sd to set default should NEVER be done in the system login procedure.