u3369429@seismo.CSS.GOV@murdu.OZ.AU (03/05/87)
Sorry, I can't this one let go un-answered. In article <8703030035.AA24496@ucbvax.Berkeley.EDU> McGuire_Ed@GRINNELL.MAILNET writes: >*Flame ON* > >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?) >1. If I write nifty COMs just for my own account, I find myself learning the > idiosyncrasies of my own custom environment, and forgetting how the vanilla > environment behaves. It really makes me a less effective resource. Well, that reflects probably more of your idiosyncrasies than it is proof of the sufficiency of vanilla VMS. >2. If I write nifty COMs for everyone, lots of bad things happen: > - I have to maintain them > - They aren't in the VMS docset, so it's hard to find them in the index :-) > - Most students who go to another VMS site when they enter the workforce > find themselves relearning DCL 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. >3. COMs are more expensive than standard commands. Every time someone uses > one, file system overhead is incurred to open and close, and several lines > of DCL are executed. Just for illustration: Heaven help you if you replace > the DIR command with a front-end! On my system, DIRECTORY is often invoked > more frequently than any other command. 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. The procedure I use for SET DEFAULT is expensive. In fact, I usually don't use it on a 750. But it provides me with a stack of 8 directories that I've visited which I can refer to by menu selection. That saves me a lot of typing. I think the overall effect is a positive gain. Have you tried to define the shifted function keys on your VT220 just by using DCL? Congratulations. How do you lock your terminal from un-authorised use when you leave it? 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? >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?) > - They could add `DELETE/DIRECTORY [obsoletedir]' > - They could provide an easy way to test the directory bit in the file > header, also for programmers > - and on, and on . . . And why haven't they? Why does the SUBMIT command create the .LOG file in SYS$LOGIN by default? >*Flame OFF* > >Ed McGuire >Grinnell College >MCGUIRE@GRIN2.BITNET Michael Bednarek (u3369429@murdu.oz.au)