Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!mcvax!ukc!kcl-cs!glasgow!taylor
From: taylor@glasgow.glasgow.UUCP (Jem Taylor)
Newsgroups: net.decus,net.unix,net.usenix
Subject: Re: Favorite operating systems query (UNIX vs VMS flaming!!!)
Message-ID: <675@glasgow.glasgow.UUCP>
Date: Sun, 10-Aug-86 17:13:46 EDT
Article-I.D.: glasgow.675
Posted: Sun Aug 10 17:13:46 1986
Date-Received: Wed, 13-Aug-86 01:35:37 EDT
References: <486@batcomputer.TN.CORNELL.EDU> <1000@ttrdc.UUCP>
Reply-To: taylor@glasgow.UUCP (Jem Taylor)
Organization: Comp Sci Dept, Glasgow Univ, Scotland
Lines: 123
Summary: Bucket of cold ... petrol.
Xref: mnetor net.decus:370 net.unix:5184 net.usenix:251

In article <859@kbsvax.steinmetz.UUCP> davidsen@kbsvax.UUCP (Davidsen) writes:
>In article <909@rti-sel.UUCP> rcb@rti-sel.UUCP (Random) writes:
>>In article <1320@psivax.UUCP> friesen@psivax.UUCP (Stanley Friesen) writes:
>>>In article <873@rti-sel.UUCP> rcb@rti-sel.UUCP (Random) writes:
>>>>
>	the original pro-VMS statement
>>>>No. VMS programs will not let you invoke them with bogus arguments. Since
>>>>the arguments are parsed by DCL before the program is invoked, if you give
>>>>too many parameters or an unknown switch DCL will reject it with an error
>>>>message that points out the specific problem.
...
>overkill flame, the poster didn't say (or, could it be, didn't know)
>that the user can define his/her commands with a mechanism similar to
>an alias, and get no parameter checking at all. It can even be put in a
>startup file and done at login.
>
>Examples: (! starts comments)
>  $ check:==$usr$disk:[user.bin]check.exe ! binary executable image
>  $ redo:==@usr$disk:[user.bin]redo.com   ! DCL (shell) command file
>     |   | |________________________ $ for binary, @ for DCL shell
>     |   |__________________________ mystic assignment operator
>     |______________________________ symbol now defined as valid command
>
mystic, yes, but powerful. And much of unix is mystic of course ...

	= and := are 'local' symbol assigns - like 'set'
	== and :== are 'global' - like setenv

(except that unlike set and setenv, these things are _also_ usable as aliases
as in csh )

	the ':' suppresses symbol substition on the RHS unless the symbol is
	explicitly quoted.
Thus
	A == B
and
	A:== 'B'
are equivalent. If you don't use ':', you need '"' around strings. The example
here sets C to a string, rather than A to the VALUE OF B as above :

	C == "text"
or
	C :== text

Like everything, once you are used to it, it's fine.


>I hope this has spread some rational light on the subject. The ability
>to have the arguments parsed is very useful, but time consuming for the
>system operator. The method described above provides no checking, but
>is easily doable by the user. It is far easier to write commands
>knowing that they will never get bad arguments than to put recovery
>code in each and every program. VMS provides both.
>
It's NOT time consuming for the operator. The .CLD (Command language definition)
of a command is written by the author at the same time as the command. I write
my .CLD first, then the .HLP ( Help ) input for the LIBRARY/HELP command, and
finally code the command itself. This ensures that the command interface is
properly defined and that the help page is true; finally the code has to
conform to the definition.
The .HLP file is incorporated into the system help library at installation of
the command, and the .CLD is incorporated into the system command table at
the same time - once only. This is akin to putting the files into /bin and
/usr/man (or wherever) - which always strikes me as rather ad hoc, the set
of available commands being a one-to-one mapping to the contents of certain
directories of the filestore.

One very powerful aspect of .CLD which no-one mentions is the 'image' keyword,
which defines where the executable image is to be found. If no image is
specified,
	SYS$SYSTEM:command_name.EXE
is assumed, but the file can be put anywhere and need not have the same name
as the command.
Even more powerful is the use in this example:

define verb mycommand
	image	userdisk:[mydir]mycommand1.exe
	....
	qualifier	special	syntax=otherformat

define syntax otherformat
	image	otherdisk:[mydir]mycommand2.exe

with this definition, 'myco' (DCL supports unique truncation of the command
verb) will invoke the image mycommand1, but 'mycom/spe' enforces the alternate
syntax of the command and invokes a different image. This means that a number
of different programs can be given the same name, as in DEFINE (define a
logical name for a device), DEFINE/KEY (redefine the keyboard) etc, but invoke
unrelated images. I have used this mechanism to support the use of two images
with common code, one small and fast for the common options, the other more
powerful but larger and slower. Users need not know that they are using 
different images, and do not need to remember which of 'prog', 'xprog' or
'nprog3' they should be using this week.

>Please don't count me as pro-VMS, I have used it since we got our first
>VAX (I believe it was S/N < 30) and still only consider it acceptable.
>I find the UNIX interface more convenient and the response far better
>for small programs due to the overhead of process start in VMS.
>Flamers, please MEASURE the overhead for UNIX and VMS on similar
>machines (in cpu or disk access) before rebutting this.

In my experience of VMS 782's and 785's versus Unix 750's and 780's, I find
the above to be true ( SPAWN takes an age in VMS ), but the VMS systems
seem to degrade more gracefully when too many users are logged on. The Unix
system seems to give up completely when overloaded. Obviously page and swap
space tuning and the myriad sysgen parameters under VMS give a diligent
system manager more scope to fit the machine to the performance demanded of
it.

-Jem.	I'm very happy with my 42nix WCW MG-1 workstation - thou' it did
crash completely the other day when I put 25+ clocks on the screen, all with
the second hand moving, and tried to move them around *fast*.

-- 

________________________________________________________________________________

JANET:   taylor@uk.ac.glasgow.cs                 -o     Jemima
USENET:  {ukc,ucl-cs}!cs.glasgow.ac.uk!taylor     (=-)   Puddleduck
ARPANET: taylor%cs.glasgow.ac.uk@ucl-cs.arpa
Phone:   +44 (0)41 339-8855 extn. 6054
Mail:    J.A.Taylor, Computer Science, 17 Lilybank Gardens, GB-GLASGOW G12 8QQ
________________________________________________________________________________