🚀 go-pugleaf

In article <486@batcomputer.TN.CORNELL.EDU> garry writes:
>I've been subjected to an unpleasantly large number of operating systems
>over the years (is WYLBUR still out there somewhere?), and I'm a VMS
>
>-- 
>garry wiegand   (garry%cadif-oak@cu-arpa.cs.cornell.edu)

WYLBUR is alive and well at various government institutions.
Aside from Montgomery County Community College, is MUSIC still out
there anywhere?

-dave
-- 
David Hsu  (301) 454-1433 || -8798	"It was Dave, not me..honest!" -eneevax
Communication & Signal Processing Lab / Engineering Computer Facility
The University of Maryland   -~-   College Park, MD 20742
ARPA:hsu@eneevax.umd.edu  UUCP:[seismo,allegra,rlgvax]!umcp-cs!eneevax!hsu

"Unlike me, many of you have accepted your situation and will die here like
 rotten cabbages..."  -Number 6

In article <486@batcomputer.TN.CORNELL.EDU>, garry@batcomputer.TN.CORNELL.EDU (Garry Wiegand) writes:
>I've been subjected to an unpleasantly large number of operating systems
>over the years (is WYLBUR still out there somewhere?), and I'm a VMS
>partisan. What comes to mind quickly:
>
>1) Command names and switch names are reasonable, in English, and consistent
>   across all the different programs. I don't have to carry a stupid encoding
>   table around in my head.

Oh yes, and along with those verbose commands goes a command line which can't
be over 255 characters long, and a library-archiver, compiler, and linker
which can't take wild cards.  Real nice when you have a 100-module program.

Most Unix programs will print out a line or so of "usage" diagnostics if you
invoke them with bogus arguments.  Do VMS programs do this?

>
>2) The on-line Help is well-indexed, and it's HUGE. They've recently started
>   digesting the language references into Help entries; I rarely need
>   to page through a manual anymore.

Tell me, is there one for the Fortran under VMS 4.x?  On our 3.x VMS systems,
we did indeed have a detailed online help for Fortran, and we have such a
help now for C, but not for Fortran.  Did someone just forget to install it,
(system manager is baffled) or is it an "extra" (cost) item, or what?

Unix online help need not be "HUGE" because the system interface isn't "HUGE."
I think VMS is marvelous from many user points of view (despite my criticisms
herein) but the system interface is a monstrous headache because of the
complexity.

>
>3) The source-line debugger is exceedingly useful for program development and
>   (after several years of hard work at DEC) I can say it works well.

That's nice, BUT what do you do when the program dies in an alpha-test
environment?  You get a nice stack-dump printout, but do you get a "core"
which can be analyzed (especially if the sequence leading up the the crash
is not easily reproducible?).  (I _think_ there was supposed to be an option
to RUN which would cause a program to produce the VMS equivalent of a core
dump when it dies, but then can you pass parameters to the program, which
as best as I understand cannot be done with RUN?)

>
>4) The system services are logical, consistent, and well-documented. Anything
>   a utility can do, a user program can do too. (And if you want to tickle the
>   kernel, there *is* a thick manual on the system internals.)

Could you then do me a favor.  Show me how, in Fortran, I would go about
setting the protection (no fancy ACL stuff, just basic RWED protections)
on a file which I am creating.  (In C it's easy enough, since the protec-
tion is specified when the file is created, which of course is tied to the
straightforward Unix way of doing things!)  Please show actual code, such as
a USEROPEN program, together with the OPEN() statement that calls it, to run
on VMS 4.2.  Or even show me how I can do it in assembler.  (I hesitate to
say show me how to do it in the system programming language, since Bliss-32
is an "extra-cost" [and not really very commonly used outside of DEC, unlike
C which is commonly used outside of Unix systems, let alone AT&T machines]
option which I don't have.  I think the analogy fair since that is what I
would probably do if I needed to change the protection of a Unix file from
Fortran [I would call chmod() in a C routine].)

See also my comments under 2) about the system interface.  It is massive,
complex, and cumbersome, as well as introducing kludges into common pro-
gramming languages, to be blunt.  VMS does indeed pride itself on
accessibility of system routines from "any" language, but this occurs at
the cost of kludgey extensions (like Fortran STRUCTUREs and RECORDs and
%val()s and %loc()s) to common programming languages, that a user would
actually WANT to program in.  C, which is a fairly common, "ordinary"
programming language and sees wide use and portability even in non-Unix
environments, fits the UNIX system interface very naturally and needs no
such kludges to use it.  (It is commendable that DEC has seen fit to switch
rather than fight, and has provided an extensive UNIX-like interface to
the VMS system within C.)

>
>5) VMS, she doesn't die, she doesn't break, she doesn't lose files, she
>   just keeps running along. It's pretty trustworthy.

Oh yes, remember the security hole in VMS 4.1 about a nonprivileged user
being able to crash the system by entering certain line-editing sequences
in response to a prompt (involving ^B and some other escape codes).  I
succeeded in doing this once from DCL, and we have a plain VMS system, no
special private kernel drivers installed.  VMS 4.2 also kicked the bucket
on me the other week when I was trying to access the help library.  The
system just barfed, and the console dump contained my process name.  And
I wasn't even trying any funny business or having any special privileges.
Needless to say, Unix has never done this kind of thing.

It is indeed possible for Unix files to get trashed if they have been "writ-
ten" on (to the buffer cache) at a time which is less than the periodic system
buffer flush period (typically 10-20 seconds) before a physical failure.  It
is however possible under SysV (and maybe BSD, but I'm not sure) to
open() a file with an O_SYNC option, which will not return from the write()
until the data has physically gone onto the storage medium.  To do this is,
unsurprisingly, much less efficient, but that, as with VMS RMS, is the price
which is paid for security.  Any user also can tell the system to flush the
entire buffer cache with the sync() call, if they are worried about the
integrity of what they have just written.

>
>I like MacIntoshes too, but that operating system is still in its infancy -
>"Inside the Mac" is not recommended light reading.
>
>PS - I don't buy the argument about "portable systems"! This industry is much
>   too young to constrain itself to just one way of doing things. In the
>   graphics system I designed last winter, I stole good ideas wherever I
>   found them. From VMS, Unix, the Mac, even one from IBM! Not to mention
>   all the "graphics packages" that had gone before.
>
>   In diversity there is much richness.

If so, I am exceedingly glad that UNIX is part of that richness.
(Diversity of hardware, too, spell that "vendor independence.")

>
>
>--
>garry wiegand   (garry%cadif-oak@cu-arpa.cs.cornell.edu)
-- 
 -------------------------------    Disclaimer:  The views contained herein are
|       dan levy | yvel nad      |  my own and are not at all those of my em-
|         an engihacker @        |  ployer or the administrator of any computer
| at&t computer systems division |  upon which I may hack.
|        skokie, illinois        |
 --------------------------------   Path: ..!{akgua,homxb,ihnp4,ltuxa,mvuxa,
						vax135}!ttrdc!levy

In article <486@batcomputer.TN.CORNELL.EDU>, garry@batcomputer.TN.CORNELL.EDU (Garry Wiegand) writes:
>I've been subjected to an unpleasantly large number of operating systems
>over the years (is WYLBUR still out there somewhere?), and I'm a VMS
>partisan. What comes to mind quickly:
>
>1) Command names and switch names are reasonable, in English, and consistent
>   across all the different programs. I don't have to carry a stupid encoding
>   table around in my head.

Oh yes, and along with those verbose commands goes a command line which can't
be over 255 characters long, and a library-archiver, compiler, and linker
which can't take wild cards.  Real nice when you have a 100-module program.

Most Unix programs will print out a line or so of "usage" diagnostics if you
invoke them with bogus arguments.  Do VMS programs do this?

>
>2) The on-line Help is well-indexed, and it's HUGE. They've recently started
>   digesting the language references into Help entries; I rarely need
>   to page through a manual anymore.

Tell me, is there one for the Fortran under VMS 4.x?  On our 3.x VMS systems,
we did indeed have a detailed online help for Fortran, and we have such a
help now for C, but not for Fortran.  Did someone just forget to install it,
(system manager is baffled) or is it an "extra" (cost) item, or what?

Unix online help need not be "HUGE" because the system interface isn't "HUGE."
I think VMS is marvelous from many user points of view (despite my criticisms
herein) but the system interface is a monstrous headache because of the
complexity.

>
>3) The source-line debugger is exceedingly useful for program development and
>   (after several years of hard work at DEC) I can say it works well.

That's nice, BUT what do you do when the program dies in an alpha-test
environment?  You get a nice stack-dump printout, but do you get a "core"
which can be analyzed (especially if the sequence leading up the the crash
is not easily reproducible?).  (I _think_ there was supposed to be an option
to RUN which would cause a program to produce the VMS equivalent of a core
dump when it dies, but then can you pass parameters to the program, which
as best as I understand cannot be done with RUN?)

>
>4) The system services are logical, consistent, and well-documented. Anything
>   a utility can do, a user program can do too. (And if you want to tickle the
>   kernel, there *is* a thick manual on the system internals.)

Could you then do me a favor.  Show me how, in Fortran, I would go about
setting the protection (no fancy ACL stuff, just basic RWED protections)
on a file which I am creating.  (In C it's easy enough, since the protec-
tion is specified when the file is created, which of course is tied to the
straightforward Unix way of doing things!)  Please show actual code, such as
a USEROPEN program, together with the OPEN() statement that calls it, to run
on VMS 4.2.  Or even show me how I can do it in assembler.  (I hesitate to
say show me how to do it in the system programming language, since Bliss-32
is an "extra-cost" [and not really very commonly used outside of DEC, unlike
C which is commonly used outside of Unix systems, let alone AT&T machines]
option which I don't have.  I think the analogy fair since that is what I
would probably do if I needed to change the protection of a Unix file from
Fortran [I would call chmod() in a C routine].)

See also my comments under 2) about the system interface.  It is massive,
complex, and cumbersome, as well as introducing kludges into common pro-
gramming languages, to be blunt.  VMS does indeed pride itself on
accessibility of system routines from "any" language, but this occurs at
the cost of kludgey extensions (like Fortran STRUCTUREs and RECORDs and
%val()s and %loc()s) to common programming languages, that a user would
actually WANT to program in.  C, which is a fairly common, "ordinary"
programming language and sees wide use and portability even in non-Unix
environments, fits the UNIX system interface very naturally and needs no
such kludges to use it.  (It is commendable that DEC has seen fit to switch
rather than fight, and has provided an extensive UNIX-like interface to
the VMS system within C.)

>
>5) VMS, she doesn't die, she doesn't break, she doesn't lose files, she
>   just keeps running along. It's pretty trustworthy.

Oh yes, remember the security hole in VMS 4.1 about a nonprivileged user
being able to crash the system by entering certain line-editing sequences
in response to a prompt (involving ^B and some other escape codes).  I
succeeded in doing this once from DCL, and we have a plain VMS system, no
special private kernel drivers installed.  VMS 4.2 also kicked the bucket
on me the other week when I was trying to access the help library.  The
system just barfed, and the console dump contained my process name.  And
I wasn't even trying any funny business or having any special privileges.
Needless to say, Unix has never done this kind of thing.

It is indeed possible for Unix files to get trashed if they have been "writ-
ten" on (to the buffer cache) at a time which is less than the periodic system
buffer flush period (typically 10-20 seconds) before a physical failure.  It
is however possible under SysV (and maybe BSD, but I'm not sure) to
open() a file with an O_SYNC option, which will not return from the write()
until the data has physically gone onto the storage medium.  To do this is,
unsurprisingly, much less efficient, but that, as with VMS RMS, is the price
which is paid for security.  Any user also can tell the system to flush the
entire buffer cache with the sync() call, if they are worried about the
integrity of what they have just written.

>
>I like MacIntoshes too, but that operating system is still in its infancy -
>"Inside the Mac" is not recommended light reading.
>
>PS - I don't buy the argument about "portable systems"! This industry is much
>   too young to constrain itself to just one way of doing things. In the
>   graphics system I designed last winter, I stole good ideas wherever I
>   found them. From VMS, Unix, the Mac, even one from IBM! Not to mention
>   all the "graphics packages" that had gone before.
>
>   In diversity there is much richness.

If so, I am exceedingly glad that UNIX is part of that richness.

>
>
>--
>garry wiegand   (garry%cadif-oak@cu-arpa.cs.cornell.edu)
-- 
 -------------------------------    Disclaimer:  The views contained herein are
|       dan levy | yvel nad      |  my own and are not at all those of my em-
|         an engihacker @        |  ployer or the administrator of any computer
| at&t computer systems division |  upon which I may hack.
|        skokie, illinois        |
 --------------------------------   Path: ..!{akgua,homxb,ihnp4,ltuxa,mvuxa,
						vax135}!ttrdc!levy


-- 
 -------------------------------    Disclaimer:  The views contained herein are
|       dan levy | yvel nad      |  my own and are not at all those of my em-
|         an engihacker @        |  ployer or the administrator of any computer
| at&t computer systems division |  upon which I may hack.
|        skokie, illinois        |
 --------------------------------   Path: ..!{akgua,homxb,ihnp4,ltuxa,mvuxa,
						vax135}!ttrdc!levy

In article <1000@ttrdc.UUCP> levy@ttrdc.UUCP (Daniel R. Levy) writes:
>Could you then do me a favor.  Show me how, in Fortran, I would go about
>setting the protection (no fancy ACL stuff, just basic RWED protections)
>on a file which I am creating.  (In C it's easy enough, since the protec-
>tion is specified when the file is created, which of course is tied to the
>straightforward Unix way of doing things!)  Please show actual code, such as
>a USEROPEN program, together with the OPEN() statement that calls it, to run
>....
The following is a trivial (and slow) way to do this.  I'm sure there is a 
better way but sitting here this is the best I can do.

       OPEN()
       ...
       Close()
       Call Lib$Spawn('Set Protection=....')


Personally I love to play with UNIX.  It is a lot of fun to poke around in.
On the other hand when I need to get things done I like VMS.  It is easy
because I don't need to think about how to do thinks, only about what I'm
trying to get done.  When I first started on VMS I just sat down at a terminal
and started to see if I could make it go.  My first command was EDIT TEST and
it worked!  Love at first sight.  I would never have guessed vi.  

Now that I know a little about UNIX I like it.  What I like about VMS is 
that I didn't need to take two weeks of workshops to learn enough to be
able to use it.

John Thurtell 
 

I promised myself that I was going to stay out of this annual OS debate.
However, I weakened. So here it comes.

In article <1000@ttrdc.UUCP> levy@ttrdc.UUCP writes:
>In article <486@batcomputer.TN.CORNELL.EDU>, garry@batcomputer.TN.CORNELL.EDU (Garry Wiegand) writes:
>>1) Command names and switch names are reasonable, in English, and consistent
>>   across all the different programs. I don't have to carry a stupid encoding
>>   table around in my head.
>
>Oh yes, and along with those verbose commands goes a command line which can't
>be over 255 characters long, and a library-archiver, compiler, and linker
>which can't take wild cards.  Real nice when you have a 100-module program.
>

The librarian and most compilers WILL take wildcards and have done so for
some time. True the linker won't which is a bother. However, it would be nice
if you check your arguments before posting them.

>Most Unix programs will print out a line or so of "usage" diagnostics if you
>invoke them with bogus arguments.  Do VMS programs do this?
>

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.

>>
>>2) The on-line Help is well-indexed, and it's HUGE. They've recently started
>>   digesting the language references into Help entries; I rarely need
>>   to page through a manual anymore.
>
>Tell me, is there one for the Fortran under VMS 4.x?  On our 3.x VMS systems,
>we did indeed have a detailed online help for Fortran, and we have such a
>help now for C, but not for Fortran.  Did someone just forget to install it,
>(system manager is baffled) or is it an "extra" (cost) item, or what?
>

This is the fault of your system manager for not reading the installation
document that came with the fortran compiler. There are really 2 distributions
on the tape. One for fortran and one for the help and the help is even more
extensive than the one on 3.x.

>Unix online help need not be "HUGE" because the system interface isn't "HUGE."
>I think VMS is marvelous from many user points of view (despite my criticisms
>herein) but the system interface is a monstrous headache because of the
>complexity.
>

VMS online help is HUGE because it is complete. Unix help on the other hand...

>>
>>3) The source-line debugger is exceedingly useful for program development and
>>   (after several years of hard work at DEC) I can say it works well.
>
>That's nice, BUT what do you do when the program dies in an alpha-test
>environment?  You get a nice stack-dump printout, but do you get a "core"
>which can be analyzed (especially if the sequence leading up the the crash
>is not easily reproducible?).  (I _think_ there was supposed to be an option
>to RUN which would cause a program to produce the VMS equivalent of a core
>dump when it dies, but then can you pass parameters to the program, which
>as best as I understand cannot be done with RUN?)
>
A program can be linked to cause a "core" dump. Also, the core dump is 
analysed by the symbolic debugger.

>>
>>4) The system services are logical, consistent, and well-documented. Anything
>>   a utility can do, a user program can do too. (And if you want to tickle the
>>   kernel, there *is* a thick manual on the system internals.)
>
>Could you then do me a favor.  Show me how, in Fortran, I would go about
>setting the protection (no fancy ACL stuff, just basic RWED protections)
>on a file which I am creating.  (In C it's easy enough, since the protec-
>tion is specified when the file is created, which of course is tied to the
>straightforward Unix way of doing things!)  Please show actual code, such as
>a USEROPEN program, together with the OPEN() statement that calls it, to run
>on VMS 4.2.  Or even show me how I can do it in assembler.  (I hesitate to
>say show me how to do it in the system programming language, since Bliss-32
>is an "extra-cost" [and not really very commonly used outside of DEC, unlike
>C which is commonly used outside of Unix systems, let alone AT&T machines]
>option which I don't have.  I think the analogy fair since that is what I
>would probably do if I needed to change the protection of a Unix file from
>Fortran [I would call chmod() in a C routine].)
>

Since I don't write in fortran, I can't give you the exact details, but
the useropen routine should allocate a protection XAB and link it to the FAB
passed into the useropen routine. When the open occurs, the protection
will be right.

>See also my comments under 2) about the system interface.  It is massive,
>complex, and cumbersome, as well as introducing kludges into common pro-
>gramming languages, to be blunt.  VMS does indeed pride itself on
>accessibility of system routines from "any" language, but this occurs at
>the cost of kludgey extensions (like Fortran STRUCTUREs and RECORDs and
>%val()s and %loc()s) to common programming languages, that a user would
>actually WANT to program in.  C, which is a fairly common, "ordinary"
>programming language and sees wide use and portability even in non-Unix
>environments, fits the UNIX system interface very naturally and needs no
>such kludges to use it.  (It is commendable that DEC has seen fit to switch
>rather than fight, and has provided an extensive UNIX-like interface to
>the VMS system within C.)
>
Fortran structures, records, etc. do not exist for the purpose of kludgey
interfaces to system routines. They exist to enhance fortran's capabilities.
Structures and records provide better programming practices and %val and
%loc allow rather sophisticated pointer operations to be done.
>>
>>5) VMS, she doesn't die, she doesn't break, she doesn't lose files, she
>>   just keeps running along. It's pretty trustworthy.
>
>Oh yes, remember the security hole in VMS 4.1 about a nonprivileged user
>being able to crash the system by entering certain line-editing sequences
>in response to a prompt (involving ^B and some other escape codes).  I
>succeeded in doing this once from DCL, and we have a plain VMS system, no
>special private kernel drivers installed.  VMS 4.2 also kicked the bucket
>on me the other week when I was trying to access the help library.  The
>system just barfed, and the console dump contained my process name.  And
>I wasn't even trying any funny business or having any special privileges.
>Needless to say, Unix has never done this kind of thing.
>
Would you mind also including the list of unix kernal bugs that can be activated
by any user to kill the system. Assuming that there is disk space to keep the
list. The above bug makes a good example for you to point to because it
stands out. The reason it stands out is because it is the ONLY bug of it's kind
I have ever seen since about version 2.5

>It is indeed possible for Unix files to get trashed if they have been "writ-
>ten" on (to the buffer cache) at a time which is less than the periodic system
>buffer flush period (typically 10-20 seconds) before a physical failure.  It
>is however possible under SysV (and maybe BSD, but I'm not sure) to
>open() a file with an O_SYNC option, which will not return from the write()
>until the data has physically gone onto the storage medium.  To do this is,
>unsurprisingly, much less efficient, but that, as with VMS RMS, is the price
>which is paid for security.  Any user also can tell the system to flush the
>entire buffer cache with the sync() call, if they are worried about the
>integrity of what they have just written.
>
Please let us not forget the great fun of trying to overwrite a file when
the file system is full. The write fails as would be expected but has the
nasty side effect of leaving a zero length file. Goodby data.
>>
>>I like MacIntoshes too, but that operating system is still in its infancy -
>>"Inside the Mac" is not recommended light reading.
>>
>>PS - I don't buy the argument about "portable systems"! This industry is much
>>   too young to constrain itself to just one way of doing things. In the
>>   graphics system I designed last winter, I stole good ideas wherever I
>>   found them. From VMS, Unix, the Mac, even one from IBM! Not to mention
>>   all the "graphics packages" that had gone before.
>>
>>   In diversity there is much richness.
>
>If so, I am exceedingly glad that UNIX is part of that richness.
>
>>
>>
>>--
>>garry wiegand   (garry%cadif-oak@cu-arpa.cs.cornell.edu)
>-- 
> -------------------------------    Disclaimer:  The views contained herein are
>|       dan levy | yvel nad      |  my own and are not at all those of my em-
>|         an engihacker @        |  ployer or the administrator of any computer
>| at&t computer systems division |  upon which I may hack.
>|        skokie, illinois        |
> --------------------------------   Path: ..!{akgua,homxb,ihnp4,ltuxa,mvuxa,
>						vax135}!ttrdc!levy

Before you get the idea that I am a rabid UNIX hater, I actually like some
features of unix. I prefer VMS for it's consistancy, reliability and
versatility. There are many unix emulators on VMS because it has the power
and flexability to do a lot of different things easily. I have never seen
a VMS emulator on unix however. And as for the good things about unix,
I have ported or duplicated them on VMS so that I now have the best of both
worlds.
-- 
					Random (Randy Buckland)
					Research Triangle Institute
					...!mcnc!rti-sel!rcb

[Bug food.  No, who wants to feed a bug?!  Bug killer, I guess.]

     Some history.  I started on VMS and switched to UNIX as soon  as we
got it.   So  my  view is not generated by lack of  knowledge  of either
system.  In fact I am the local wizard for both of  them (and lemme tell
you it's not always a pleasant thing to be!).

>> [...] I'm a VMS partisan. What comes to mind quickly:
>> 3) The source-line debugger is exceedingly useful for program
>> development and (after several years of hard work at DEC) I can say
>> it works well.
> That's nice, BUT what do you do when the program dies in an alpha-test
> environment?  You get a nice stack-dump printout, but do you get a "core"
> which can be analyzed (especially if the sequence leading up the the crash
> is not easily reproducible?).

     The really good debugger is the only thing I miss at all often from
when I used VMS.  In fact it's very close to the  only thing I miss from
VMS at all.

>> 4) The system services are logical, consistent, and well-documented.
>> Anything a utility can do, a user program can do too.

     Let's  see a user program  implement  DCL.   Or DEBUG.  Okay, those
really aren't fair, are  they?  (But under  UNIX, on the other hand...).
Or any  of  the  DCL  builtins, like  ASSIGN,  DEFINE,  ATTACH, DEPOSIT,
EXAMINE, ...

     I want  to  see where the documentation  exists to  tell me  how to
perform the functions of the following commands from a user program; let
us be kind to you and postulate I am writing in assembly:
	- DISMOUNT (where is sys$library:dismntshr mentioned?)
	- INITIALIZE
	- UNLOCK
and  probably  others I can't  find in  10 minutes.  I  don't want to be
referred to the internals manual; see the next comment.

>> (And if you want to tickle the kernel, there *is* a thick manual on
>> the system internals.)

     Which costs what  was it,  a thousand  dollars?  To  a  university?
Sorry.  UNIX kernel *source* (not just documentation that only tells you
how, source that shows you how and that you can fix bugs  in) comes with
it.

>> [the above item 4]
> Could you then do me a favor.  Show me how, in Fortran, I would go about
> setting the protection (no fancy ACL stuff, just basic RWED protections)
> on a file which I am creating.

     I second this challenge, IN FORTRAN.

> Or even show me how I can do it in assembler.

     RTFM, I'm sorry  to say.   I am writing this from the RMS reference
manual, I do not remember all this stuff!

fab:	$fab	xab = xab 	;anything else you want here, like file
				;attributes or record attributes
xab:	$xabpro pro=<rwe,rwed,re,e> ;can also be set at runtime, see
				;the manual
	....maybe set filename in fab or something....
	$create	fab=fab		;if creating on the spot, do just this
	$open	fab=fab		;otherwise, open, change the xab, and
	movw	something,<xab+xab$w_pro> ;close again
	$close	fab=fab

This  could  be worked into  a  useropen  procedure  easily if I had the
FORTRAN manual handy, though the useropen procedure would be in MACRO.

> VMS does indeed pride itself on accessibility of system routines from
> "any" language,

and then  neglects  to mention that  (for  example)  to access  the  RMS
service $create from a high-level  language you create  a FAB  structure
(field  order and some  contents  not documented) and  call sys$create()
with  this  structure.    I  learned  this  through   a  combination  of
intelligent guessing and reading other people's code.

>> 5) VMS, she doesn't die, she doesn't break, she doesn't lose files,
>> she just keeps running along. It's pretty trustworthy.

     I can write you a real trustworthy system.

	spl7();
	while (1); /* note semicolon */

My point,  of course, is that functionality  must be considered as well.
By the way, VMS  *does* break on occaison, and when it does, you haven't
a ghost of a chance of figuring out why.  On UNIX, on the other hand....

>> I like MacIntoshes too, but that operating system is still in its
>> infancy - "Inside the Mac" is not recommended light reading.

     Neither is the VMS internals manual....

>> PS - I don't buy the argument about "portable systems"! This
>> industry is much too young to constrain itself to just one way of
>> doing things.  [...] In diversity there is much richness.

     Like constraining yourself to running on a VAX?  Riiight.
-- 
					der Mouse

USA: {ihnp4,decvax,akgua,utzoo,etc}!utcsri!mcgill-vision!mouse
     philabs!micomvax!musocs!mcgill-vision!mouse
Europe: mcvax!decvax!utcsri!mcgill-vision!mouse
        mcvax!seismo!cmcl2!philabs!micomvax!musocs!mcgill-vision!mouse
ARPAnet: utcsri!mcgill-vision!mouse@uw-beaver.arpa

"Come with me a few minutes, mortal, and we shall talk."

> 
> Before you get the idea that I am a rabid UNIX hater, I actually like some
> features of unix. I prefer VMS for it's consistancy, reliability and
> versatility. There are many unix emulators on VMS because it has the power
> and flexability to do a lot of different things easily. I have never seen
> a VMS emulator on unix however. And as for the good things about unix,
> I have ported or duplicated them on VMS so that I now have the best of both
> worlds.
> -- 
    Why would anyone want to emulate VMS on a UNIX machine. Most people just
leave good enough alone.
	By the way have you ever tried to link a VMS program which uses 
libraries with circular calls (ie. a routine in library A calls a routine in
library B which calls a routine in library A). I tried linking a graphics 
program the other day with just such a setup and I ended up listing each 
library twice thus you get one very long command line.

> 					Random (Randy Buckland)
> 					Research Triangle Institute
> 					...!mcnc!rti-sel!rcb

Geoff Coleman

disclaimer: these are not opinions

This discussion is not relevant to net.usenix.  Please delete it from
the list of newsgroups.  net.usenix is for discussions about the
USENIX association, not debates about UNIX.

		Ken Arnold

In article <873@rti-sel.UUCP>, rcb@rti-sel.UUCP (Random) writes:
>I promised myself that I was going to stay out of this annual OS debate.
>However, I weakened. So here it comes.
>In article <1000@ttrdc.UUCP> levy@ttrdc.UUCP writes:
>>Oh yes, and along with those verbose commands goes a command line which can't
>>be over 255 characters long, and a library-archiver, compiler, and linker
>>which can't take wild cards.  Real nice when you have a 100-module program.
>The librarian and most compilers WILL take wildcards and have done so for
>some time. True the linker won't which is a bother. However, it would be nice
>if you check your arguments before posting them.

I owe the net an apology; I tried it again with the LIBRARY command and yes
(whew), it does work.  So it's easy to build libraries (and in all fairness
too, the LIBRARY command is quicker than the UNIX 'ar' when inserting modules
in the middle is involved).

However, as Random admits, it won't work with the linker, and contrary to what
he says, it won't work with "most compilers" (at least not "most compilers"
that I have had opportunity to use!).  e.g. (VMS 4.2):

$ SET DEFAULT [LEVY.C]
$ DIR

Directory UD6:[LEVY.C]

FILE1.C;1           FILE2.C;1           

Total of 2 files.
$ CC *.C
%CC-F-OPENIN, error opening UD6:[LEVY.C]*.C; as input
-RMS-F-WLD, invalid wildcard operation

$ SET DEFAULT [LEVY.FORTRAN]
$ DIR

Directory UD6:[LEVY.FORTRAN]

FILE1.FOR;1         FILE2.FOR;1         

Total of 2 files.
$ FORTRAN *.FOR
%FORT-F-OPENIN, error opening UD6:[LEVY.FORTRAN]*.FOR; as input
-RMS-F-WLD, invalid wildcard operation
%FORT-F-ABORT, abort
$ SET DEFAULT [LEVY.MACRO]
$ DIR

Directory UD6:[LEVY.MACRO]

FILE1.MAR;1         FILE2.MAR;1         

Total of 2 files.
$ MACRO *.MAR
%MACRO-E-OPENIN, error opening UD6:[LEVY.MACRO]*.MAR; as input
-LIB-E-NOWILD, no wildcard permitted
$ SET DEFAULT [LEVY.MODULA2]
$ DIR

Directory UD6:[LEVY.MODULA2]

FILE1.MOD;1         FILE2.MOD;1         

Total of 2 files.
$ MODULA *.MOD
%MODULA-F-IOERR, problem during Open operation for file UD6:[LEVY.MODULA2]*.MOD;
-RMS-F-WLD, invalid wildcard operation
$ LO
  LEVY         logged out at 28-JUN-1986 20:21:04.43

(Me:)
>>Most Unix programs will print out a line or so of "usage" diagnostics if you
>>invoke them with bogus arguments.  Do VMS programs do this?
>>
(Random:)
>
>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.

Ah now, if only DCL were smart enough to give a diagnostic which is a little
more "specific" than this:

$ SHOW USERS/BOGUS
%DCL-W-IVQUAL, unrecognized qualifier - check validity, spelling, and placement
 \BOGUS\

I'd much prefer to see something like this, which is from SysV:

$ who -BOGUS
who:  illegal option -- B
Usage:	who [-rbtpludAasHTq] [am i] [utmp_like_file]

r	run level
b	boot time
t	time changes
p	processes other than getty or users
l	login processes
u	useful information
d	dead processes
A	accounting information
a	all (rbtpludA options)
s	short form of who (no time since last output or pid)
H	print header
T	status of tty (+ writable, - not writable, x exclusive open, ? hung)
q	quick who

>
>>>
>>>2) The on-line Help is well-indexed, and it's HUGE. They've recently started
>>>   digesting the language references into Help entries; I rarely need
>>>   to page through a manual anymore.
>>Tell me, is there one for the Fortran under VMS 4.x?  On our 3.x VMS systems,
>>we did indeed have a detailed online help for Fortran, and we have such a
>>help now for C, but not for Fortran.  Did someone just forget to install it,
>>(system manager is baffled) or is it an "extra" (cost) item, or what?
>This is the fault of your system manager for not reading the installation
>document that came with the fortran compiler. There are really 2 distributions
>on the tape. One for fortran and one for the help and the help is even more
>extensive than the one on 3.x.

I owe somewhat of an apology for this flame, and will go beat on my system
manager to install the fuller HELP :-).

>>Unix online help need not be "HUGE" because the system interface isn't "HUGE."
>>I think VMS is marvelous from many user points of view (despite my criticisms
>>herein) but the system interface is a monstrous headache because of the
>>complexity.
>
>VMS online help is HUGE because it is complete. Unix help on the other hand...

Well, maybe I shouldn't say that UNIX help is so small.  (WARNING: LOTS OF
TEXT FOLLOWS!)

$ ls -sRC /usr/catman
total 3        1 a_man     1 p_man     1 u_man

/usr/catman/a_man:
total 7       4 man1     2 man7     1 man8

/usr/catman/a_man/man1:
total 559               2 errstop.1m.z       3 qasurvey.1m.z
   3 Uutry.1m.z         6 ff.1m.z            3 reboot.1m.z
   2 abt.1m.z           2 filesave.1m.z      2 rmv.1m.z
   3 accept.1m.z        4 finc.1m.z          7 rst.1m.z
   7 acct.1m.z          5 format.1m.z       10 runacct.1m.z
   5 acctcms.1m.z       4 frec.1m.z          3 sadp.1m.z
   6 acctcon.1m.z      13 fsck.1m.z          7 sar.1m.z
   3 acctmerg.1m.z      6 fscv.vax.1m.z      3 setmnt.1m.z
   4 acctprc.1m.z      10 fsdb.1m.z          3 setmrf.1m.z
  14 acctsh.1m.z        4 fts.1m.z           3 shutdown.1m.z
   3 acuset.1m.z        4 fuser.1m.z         3 ssr.1m.z
   5 bdblk.1m.z         5 fwtmp.1m.z         2 sta.1m.z
   4 brc.1m.z          12 getty.1m.z         3 sysdef.1m.z
   5 checkall.1m.z     17 init.1m.z          3 tic.1m.z
   3 chmap.1m.z         7 install.1m.z      12 trenter.1m.z
   3 chroot.1m.z        5 intro.1m.z         4 uucheck.1m.z
   3 clri.1m.z          2 ipb.1m.z           3 uucico.1m.z
   3 config.3b.1m.z     2 killall.1m.z       5 uuclean.1m.z
  17 config.dc.1m.z     2 link.1m.z          6 uucleanup.1m.z
   6 cpset.1m.z        13 lpadmin.1m.z       6 uugetty.1m.z
  15 crash.1m.z         4 lpsched.1m.z       3 uusched.1m.z
   3 cron.1m.z          4 mkboot.1m.z        5 uusub.1m.z
   4 dcopy.1m.z         7 mkfs.1m.z          3 uutry.1m.z
   3 devnm.1m.z         3 mknod.1m.z         4 uuxqt.1m.z
   3 df.1m.z            3 mount.1m.z         3 vcf.1m.z
   3 dfcvers.1m.z       5 msi.1m.z           3 vlx.1m.z
   8 dgn.1m.z           2 mvdir.1m.z         6 volcopy.1m.z
   5 diskusg.1m.z       3 ncheck.1m.z       48 vpmc.dec.1m.z
   3 dmkset.1m.z        4 newboot.1m.z      24 vpmc.u3b.1m.z
   6 don.1m.z           3 non-btl.1m.z       4 vpmsave.1m.z
   3 dskfmt.1m.z        3 pcldaemon.1m.z     6 vpmset.1m.z
   5 dstart.1m.z        2 prm.1m.z           5 vpmtest.1m.z
   3 errdead.1m.z       4 profiler.1m.z      2 wall.1m.z
   3 errdemon.1m.z      3 psel.1m.z          2 whodo.1m
   6 errpt.1m.z         3 pwck.1m.z

/usr/catman/a_man/man7:
total 194             3 hm.7.z           3 osm.7.z          2 tn4.7
   4 acu.7.z          4 hp.7.z           3 pcl.7.z          2 tn74.7.z
   2 cat.7.z          3 hs.pdp.7.z       2 prf.7.z          3 tn83.7.z
   2 dgn.7.z          5 ht.7.z           3 rf.pdp.7.z       2 tn85.7.z
   2 dmc.7.z          4 intro.7.z        3 rk.pdp.7.z       5 trace.7.z
   3 dmk.7.z          2 kl.pdp.7.z       3 rl.7.z           5 ts11.7.z
   7 dsk.7.z          4 kmc.7.z          3 rm80.7.z         2 tty.7.z
   2 du.pdp.7.z       4 lp.7.z           3 rp.pdp.7.z       5 tu78.7.z
   2 dz.7.z           2 mem.7.z          3 rp07.7.z         4 un32.7.z
   2 err.7.z          2 ml11.pdp.7.z     6 sxt.7.z          2 un53.7.z
   4 gd.7.z           7 mtc.7.z         31 termio.7.z       2 vp.pdp.7.z
   2 gt.7.z           1 null.7.z         5 tm.pdp.7.z      19 vpm.7.z

/usr/catman/a_man/man8:
total 181             23 780ops.8.z        2 intro.8           7 romboot.8.z
   7 3B20boot.8.z     14 crash.dec.8.z     6 ldtape.8.z        4 tapeboot.8.z
   5 3B20ops.8.z       9 crash.u3b.8.z    12 mk.8.z            3 unixboot.8.z
  13 70boot.8.z        6 diskboot.8.z     14 prm.8.z
  16 750ops.8.z       16 eai.8.z          24 rje.8.z

/usr/catman/p_man:
total 10      2 man2     5 man3     2 man4     1 man5

/usr/catman/p_man/man2:
total 339            2 getpid.2.z      3 pipe.2.z        2 sync.2.z
   4 access.2.z      2 getuid.2.z      5 plock.2.z       4 sys3b.2.z
   4 acct.2.z       41 intro.2.z       4 profil.2.z      2 time.2.z
   2 alarm.2.z       3 ioctl.2.z      12 ptrace.2.z      4 times.2.z
   4 brk.2.z         5 kill.2.z        5 read.2.z        3 ulimit.2.z
   3 chdir.2.z       4 link.2.z       10 semctl.2.z      2 umask.2.z
   5 chmod.2.z       4 lseek.2.z       2 semget.2.z      3 umount.2.z
   4 chown.2.z      10 maus.2.z       13 semop.2.z       3 uname.2.z
   3 chroot.2.z      6 mknod.2.z       2 setpgrp.2.z     4 unlink.2.z
   2 close.2.z       4 mount.2.z       3 setuid.2.z      3 ustat.2.z
   5 creat.2.z       7 msgctl.2.z      6 shmctl.2.z      5 utime.2.z
   3 dup.2.z         6 msgget.2.z      7 shmget.2.z      6 wait.2.z
  14 exec.2.z       15 msgop.2.z       7 shmop.2.z       5 write.2.z
   5 exit.2.z        3 nice.2.z       15 signal.2.z
   5 fcntl.2.z       8 open.2.z        7 stat.2.z
   5 fork.2.z        2 pause.2.z       2 stime.2.z

/usr/catman/p_man/man3:
total 616               5 getc.3s.z          4 nlist.3c.z
   3 a64l.3c.z          3 getcwd.3c.z        3 perror.3c.z
   2 abort.3c.z         2 getenv.3c.z        6 plot.3x.z
   2 abort.3f.z         2 getenv.3f.z        4 popen.3s.z
   2 abs.3c.z           6 getgrent.3c.z     15 printf.3s.z
   3 abs.3f.z           3 getlogin.3c.z      6 putc.3s.z
   2 acos.3f.z          6 getopt.3c.z        3 putenv.3c.z
   2 aimag.3f.z         3 getpass.3c.z       3 putpwent.3c.z
   2 aint.3f.z          3 getpw.3c.z         3 puts.3s.z
   2 asin.3f.z          7 getpwent.3c.z      3 qsort.3c.z
   3 assert.3x.z        3 gets.3s.z          2 rand.3c.z
   2 atan.3f.z         10 getut.3c.z         2 rand.3f.z
   2 atan2.3f.z        12 hsearch.3c.z      10 regcmp.3x.z
   4 bessel.3m.z        2 hypot.3m.z         3 round.3f.z
   3 bool.3f.z          2 iargc.3f          14 scanf.3s.z
   7 bsearch.3c.z       2 index.3f.z         6 setbuf.3s.z
   3 clock.3c.z         9 intro.3.z          4 setjmp.3c.z
   2 conjg.3f.z         3 l3tol.3c.z         3 sign.3f.z
   4 conv.3c.z          3 ldahread.3x.z      2 signal.3f.z
   3 cos.3f.z           5 ldclose.3x.z       3 sin.3f.z
   2 cosh.3f.z          4 ldfhread.3x.z      2 sinh.3f.z
   5 crypt.3c.z         6 ldgetname.3x.z     3 sinh.3m.z
   3 ctermid.3s.z       7 ldlread.3x.z       4 sleep.3c.z
   8 ctime.3c.z         4 ldlseek.3x.z       3 sputl.3x.z
   4 ctype.3c.z         3 ldohseek.3x.z      3 sqrt.3f.z
  23 curses.3x.z        7 ldopen.3x.z        6 ssignal.3c.z
   3 cuserid.3s.z       4 ldrseek.3x.z       6 stdio.3s.z
  10 dial.3c.z          5 ldshread.3x.z      5 stdipc.3c.z
   2 dim.3f.z           4 ldsseek.3x.z       2 strcmp.3f.z
   2 dprod.3f           4 ldtbindex.3x.z    10 string.3c.z
  13 drand48.3c.z       4 ldtbread.3x.z      4 strtod.3c.z
   5 ecvt.3c.z          3 ldtbseek.3x.z      4 strtol.3c.z
   3 end.3c.z           2 len.3f             2 swab.3c.z
   2 erf.3m.z           3 log.3f.z           2 system.3f.z
   3 exp.3f.z           3 log10.3f.z         3 system.3s.z
   5 exp.3m.z           2 logname.3x.z       2 tan.3f.z
   3 fclose.3s.z        7 lsearch.3c.z       2 tanh.3f.z
   3 ferror.3s.z        6 malloc.3c.z        2 tmpfile.3s.z
   3 floor.3m.z        10 malloc.3x.z        7 tmpnam.3s.z
   7 fopen.3s.z         9 matherr.3m.z       5 trig.3m.z
   5 fread.3s.z         3 max.3f.z          13 tsearch.3c.z
   4 frexp.3c.z         2 mclock.3f.z        3 ttyname.3c.z
   5 fseek.3s.z         6 memory.3c.z        2 ttyslot.3c.z
   6 ftw.3c.z           3 min.3f.z           3 ungetc.3s.z
   9 ftype.3f.z         2 mktemp.3c.z        5 vprintf.3s.z
   3 gamma.3m.z         3 mod.3f.z           5 vprintf.3x.z
   2 getarg.3f.z        6 monitor.3c.z

/usr/catman/p_man/man4:
total 313               6 fspec.4.z          5 passwd.4.z
  16 a.out.4.z          8 gettydefs.4.z      6 plot.4.z
  12 a.out.pdp.4.z     10 gps.4.z            2 pnch.4.z
   6 acct.4.z           2 group.4.z          4 profile.4.z
   7 ar.4.z            16 inittab.4.z        7 reloc.4.z
   3 ar.pdp.4.z         3 inode.4.z         13 sccsfile.4.z
   2 checklist.4.z      2 intro.4.z          4 scnhdr.4.z
   4 core.4.z           2 issue.4.z          7 syms.4.z
   4 cpio.4.z          12 ldfcn.4.z          8 system.4.z
   2 dir.4.z            3 linenum.4.z       10 term.4.z
  12 errfile.4.z        6 master.dec.4.z    80 terminfo.4.z
   4 filehdr.4.z        5 master.u3b.4.z     5 utmp.4.z
  12 fs.4.z             3 mnttab.4.z

/usr/catman/p_man/man5:
total 144            1 intro.5.z      14 mv.5.z          3 types.5.z
   4 ascii.5.z      14 man.5.z         4 prof.5.z        5 values.5.z
   4 environ.5.z     3 math.5.z       18 regexp.5.z      6 varargs.5.z
   6 eqnchar.5.z     3 mm.5.z          3 stat.5.z
   3 fcntl.5.z       9 mosd.5.z        5 term.5.z
  22 font.5.z        3 mptx.5.z       14 troff.5.z

/usr/catman/u_man:
total 9        1 local     7 man1      1 man6

[listings of local stuff deleted to save space]

/usr/catman/u_man/man1:
total 1666             4 diff3.1.z         2 machid.1.z        4 sno.1.z
   9 300.1.z           4 diffmk.1.z        4 macref.1.z       14 sort.1.z
   3 4014.1.z          2 dircmp.1.z       10 mail.1.z          9 spell.1.z
   5 450.1.z           5 dis.1.z          52 mailx.1.z         4 spline.1g.z
  12 acctcom.1.z       3 du.1.z           30 make.1.z          2 split.1.z
  26 adb.1.z           6 dump.1.z          4 makekey.1.z       4 sroff.1.z
  22 admin.1.z         3 dx9700.1.z        2 man.1.z          17 stat.1g.z
   8 ar.1.z            2 echo.1.z          2 mesg.1.z          5 strip.1.z
   6 ar.pdp.1.z       43 ed.1.z            2 mkdir.1.z         3 strip.pdp.1.z
   2 arcv.pdp.1.z     15 edit.1.z         10 mm.1.z           19 stty.1.z
   7 as.1.z            6 efl.1.z           5 mmlint.1.z        7 su.1.z
   5 as.pdp.1.z        3 enable.1.z        6 mmt.1.z           2 sum.1.z
   3 asa.1.z           2 env.1.z           6 net.1c.z          2 sync.1.z
   9 at.1.z           13 eqn.1.z          12 newform.1.z      12 tabs.1.z
  12 awk.1.z          21 ex.1.z            5 newgrp.1.z        4 tail.1.z
   2 banner.1          7 expr.1.z          4 news.1.z          8 tar.1.z
   3 basename.1.z      8 f77.1.z           2 nice.1.z          8 tbl.1.z
   7 bc.1.z            2 factor.1.z        7 nl.1.z            5 tc.1.z
   3 bdiff.1.z         3 file.1.z          8 nm.1.z            2 tee.1
  13 bfs.1.z           8 find.1.z          4 nm.pdp.1.z        6 test.1.z
  37 bs.1.z            3 fsplit.1.z        4 nohup.1.z         2 time.1.z
   2 cal.1.z           6 gdev.1g.z        12 nroff.1.z         5 timex.1.z
   3 calendar.1.z     26 ged.1g.z         18 ocw.1.z           7 toc.1g.z
   3 cat.1.z          31 get.1.z           3 od.1.z            2 touch.1.z
   2 cb.1.z            4 getopt.1.z        7 pack.1.z          3 tplot.1g.z
  12 cc.1.z            5 graph.1g.z        5 passwd.1.z        5 tput.1.z
   3 cd.1.z            5 graphics.1g.z     6 paste.1.z         5 tr.1.z
   9 cdc.1.z           3 greek.1.z        15 pg.1.z            6 troff.1.z
   7 cflow.1.z         7 grep.1.z          2 pic.1.z           2 true.1.z
   5 chmod.1.z         7 gutil.1g.z        7 pr.1.z            2 tsort.1.z
   2 chown.1.z         3 help.1.z          8 prof.1.z          2 tty.1.z
   2 cmp.1.z           6 hp.1.z           25 prs.1.z           3 umask.1.z
   6 col.1.z          13 hpio.1.z         12 ps.1.z            5 un53ctl.1c.z
   6 comb.1.z          2 hyphen.1.z        5 ptx.1.z           2 uname.1.z
   2 comm.1.z          2 id.1              2 pwd.1             3 unget.1.z
   6 convert.1.z       5 intro.1.z         5 ratfor.1.z        3 uniq.1.z
   4 cp.1.z            4 ipcrm.1.z         4 regcmp.1.z        4 units.1.z
   8 cpio.1.z         14 ipcs.1.z          6 rjestat.1c.z     13 uucp.1c.z
  15 cpp.1.z           5 join.1.z          3 rm.1.z            7 uustat.1c.z
   2 cprs.1.z          5 kasb.1.z          4 rmdel.1.z         6 uuto.1c.z
   7 crontab.1.z       3 kill.1.z          3 sact.1.z          9 uux.1c.z
   5 crypt.1.z        10 ld.1.z            6 sag.1g.z          6 val.1.z
   8 csplit.1.z        9 ld.pdp.1.z        8 sar.1.z          10 vc.1.z
   6 ct.1c.z          10 lex.1.z           4 scc.1.z          24 vi.1.z
  21 ctrace.1.z        2 line.1.z          3 sccsdiff.1.z      3 vpr.1.z
  16 cu.1c.z          15 lint.1.z         35 sdb.1.z           2 wait.1.z
   6 cut.1.z           5 list.1.z          5 sdiff.1.z         2 wc.1.z
   4 cxref.1.z         8 login.1.z        14 sed.1.z           3 what.1.z
   5 daps.1.z          2 logname.1.z      28 send.1c.z         9 who.1.z
   5 date.1.z          3 lorder.1.z       53 sh.1.z            6 write.1.z
   8 dc.1.z            7 lp.1.z            7 shl.1.z          18 x9700.1.z
   6 dd.1.z            5 lpstat.1.z        3 size.1.z         13 xargs.1.z
  12 delta.1.z        10 ls.1.z            2 size.pdp.1.z      6 yacc.1.z
   6 diff.1.z         15 m4.1.z            2 sleep.1.z

/usr/catman/u_man/man6:
total 49                2 hangman.6.z        6 reversi.6.z
   4 arithmetic.6.z     1 intro.6.z          5 sky.6.z
   3 back.6.z           3 jotto.6.z          2 ttt.6.z
   4 bj.6.z             2 maze.6             2 wump.6.z
   3 chess.6.z          2 moo.6.z
   6 craps.6.z          4 quiz.6.z

>>>
>>>4) The system services are logical, consistent, and well-documented. Anything
>>>   a utility can do, a user program can do too. (And if you want to tickle the
>>>   kernel, there *is* a thick manual on the system internals.)
>>
>>Could you then do me a favor.  Show me how, in Fortran, I would go about
>>setting the protection (no fancy ACL stuff, just basic RWED protections)
>>on a file which I am creating.  (In C it's easy enough, since the protec-
>>tion is specified when the file is created, which of course is tied to the
>>straightforward Unix way of doing things!)  Please show actual code, such as
>>a USEROPEN program, together with the OPEN() statement that calls it, to run
>>on VMS 4.2.  Or even show me how I can do it in assembler.  (I hesitate to
>>say show me how to do it in the system programming language, since Bliss-32
>>is an "extra-cost" [and not really very commonly used outside of DEC, unlike
>>C which is commonly used outside of Unix systems, let alone AT&T machines]
>>option which I don't have.  I think the analogy fair since that is what I
>>would probably do if I needed to change the protection of a Unix file from
>>Fortran [I would call chmod() in a C routine].)
>Since I don't write in fortran, I can't give you the exact details, but
>the useropen routine should allocate a protection XAB and link it to the FAB
>passed into the useropen routine. When the open occurs, the protection
>will be right.

Well, GEEEEEEEE.  With a [SYS,LIB]$EVERYTHING_UNDER_THE_SUN, surely there
MUST be a simpler way to do this (or is there?)  Some people have suggested
using LIB$SPAWN(...,'SET PROTECTION=(whatever) FILENAME.DAT',...)
or some system call to change default protections.
Trouble is that spawning is a major undertaking under VMS, and changing the
default protections in a program I am running has the nasty side effect of
leaving them that way for the next program I run (since from DCL all user
programs from one DCL session run as part of the same process).

>>See also my comments under 2) about the system interface.  It is massive,
>>complex, and cumbersome, as well as introducing kludges into common pro-
>>gramming languages, to be blunt.  VMS does indeed pride itself on
>>accessibility of system routines from "any" language, but this occurs at
>>the cost of kludgey extensions (like Fortran STRUCTUREs and RECORDs and
>>%val()s and %loc()s) to common programming languages, that a user would
>>actually WANT to program in.  C, which is a fairly common, "ordinary"
>>programming language and sees wide use and portability even in non-Unix
>>environments, fits the UNIX system interface very naturally and needs no
>>such kludges to use it.  (It is commendable that DEC has seen fit to switch
>>rather than fight, and has provided an extensive UNIX-like interface to
>>the VMS system within C.)
>Fortran structures, records, etc. do not exist for the purpose of kludgey
>interfaces to system routines. They exist to enhance fortran's capabilities.
>Structures and records provide better programming practices and %val and
>%loc allow rather sophisticated pointer operations to be done.

Ah, but if those weren't there I'd say it would have a hard time indeed
communicating with the OS.  Also the %val and %loc and structure and record
stuff guarantees incompatibility with any other Fortran in the world.
It might be a nice programming language, but it is a superset of Fortran
and should be called such.

>>>
>>>5) VMS, she doesn't die, she doesn't break, she doesn't lose files, she
>>>   just keeps running along. It's pretty trustworthy.
>>
>>Oh yes, remember the security hole in VMS 4.1 about a nonprivileged user
>>being able to crash the system by entering certain line-editing sequences
>>in response to a prompt (involving ^B and some other escape codes).  I
>>succeeded in doing this once from DCL, and we have a plain VMS system, no
>>special private kernel drivers installed.  VMS 4.2 also kicked the bucket
>>on me the other week when I was trying to access the help library.  The
>>system just barfed, and the console dump contained my process name.  And
>>I wasn't even trying any funny business or having any special privileges.
>>Needless to say, Unix has never done this kind of thing.
>>
>Would you mind also including the list of unix kernal bugs that can be activated
>by any user to kill the system. Assuming that there is disk space to keep the
>list. The above bug makes a good example for you to point to because it
>stands out. The reason it stands out is because it is the ONLY bug of it's kind
>I have ever seen since about version 2.5

Oh yes, you want ANOTHER bug?  What about that ordinary users can make the
VMS approximation of "links" (SET FILE/ENTRY) to system files even if they
cannot write or read them.  Then if a process with proper privileges blows
these links away, VMS in its infinite wisdom blows away the CONTENTS of the
files as well as the entry!  This is not an "accidental" bug either, like the
^B bug was.

As for UNIX kernel bugs, I accept the challenge.  Any and all interested,
please send me C code which I can compile and run as a nonprivileged user
on SysVR2 to crash a 3B2, a 3B20, or a VAX, and I will either try it myself
(3B2) or submit it to people I know (and trust) to try it on the other
machines.

>Before you get the idea that I am a rabid UNIX hater, I actually like some
>features of unix. I prefer VMS for it's consistancy, reliability and
>versatility. There are many unix emulators on VMS because it has the power
>and flexability to do a lot of different things easily. I have never seen
>a VMS emulator on unix however. And as for the good things about unix,
>I have ported or duplicated them on VMS so that I now have the best of both
>worlds.
>--
>					Random (Randy Buckland)
>					Research Triangle Institute
>					...!mcnc!rti-sel!rcb

Yes, a UNIX emulator under VMS is improving things.  A VMS emulator under UNIX?
That would be an interesting research project, but what good would it do?...
(And it would of course only work on VAXen.  Forget about Amdahls, 3Bs, Pyra-
mids,...)

The VMS and UNIX paradigms are as different as night and day.
-- 
Daniel R. Levy
AT&T Computer Systems Division, Skokie, Illinois
..!ihnp4!ttrdc!levy

In article <873@rti-sel.UUCP> rcb@rti-sel.UUCP (Random) writes:
>
>>Most Unix programs will print out a line or so of "usage" diagnostics if you
>>invoke them with bogus arguments.  Do VMS programs do this?
>>
>
>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.

	Oh, *great*:-) How does the DCL parse the arguments for a user
written application program?? I can't see how it can do this without
some rather messy interface requirements.  This really sounds like a
way to make user-written programs second class citizens on the system.
I think the individual program is better qualified to analyse its own
arguments, whay is really needed is a *standard* for this, like getopts(3)!
-- 

				Sarima (Stanley Friesen)

UUCP: {ttidca|ihnp4|sdcrdcf|quad1|nrcvax|bellcore|logico}!psivax!friesen
ARPA: ??

In article <> friesen@psivax.UUCP (Stanley Friesen) writes:
>In article <873@rti-sel.UUCP> rcb@rti-sel.UUCP (Random) writes:
>>
>>>Most Unix programs will print out a line or so of "usage" diagnostics if you
>>>invoke them with bogus arguments.  Do VMS programs do this?
>>>
>>
>>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.
>
>	Oh, *great*:-) How does the DCL parse the arguments for a user
>written application program?? I can't see how it can do this without
>some rather messy interface requirements.  This really sounds like a
>way to make user-written programs second class citizens on the system.
>I think the individual program is better qualified to analyse its own
>arguments, whay is really needed is a *standard* for this, like getopts(3)!

	I'm not a VMS guru but I know enough to know that this is all
getting a little confused.  VMS programs which are not installed can
be executed either with RUN or MCR.  RUN is a general utility for
executing a user application program; MCR is another such utility with
somewhat different rules.  In particular, arguments cannot be passed
to programs invoked using RUN; however they can for programs invoked
using MCR.  System programs take options in the form of switches.  Thus:

run xyz
mcr xyz arg1 arg2 arg3
dir/col=1

[DIR is the equivalent of ls.  The slash signifies a switch (option).
In this case the output is one column per line.]

I don't know the rules for creating commands using switches.  (My
impression is that is done as part of installation -- but I just don't
know.)  In any case the DCL switch parser is the equivalent for VMS
of getopts for publicly known programs.  The difference is that you
have to describe to the system what rules your options (switches)
follow if your program is a public program.  When your program is
invoked the DCL validates the arguments before the program is brought
up.  DISCLAIMER -- this is just my impression; someone with VMS systems
experience should clarify the matter.  However, if my understanding is
correct, then this is a perfectly reasonable way to do things  -- I
would count it as preferable since it insists that options in public
(system wide) utilities be handled in a standardized manner.

		Richard Harter SMDS Inc.

In article <1320@psivax.UUCP> friesen@psivax.UUCP (Stanley Friesen) writes:
>In article <873@rti-sel.UUCP> rcb@rti-sel.UUCP (Random) writes:
>>
>>>Most Unix programs will print out a line or so of "usage" diagnostics if you
>>>invoke them with bogus arguments.  Do VMS programs do this?
>>>
>>
>>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.
>
>	Oh, *great*:-) How does the DCL parse the arguments for a user
>written application program?? I can't see how it can do this without
>some rather messy interface requirements. 
>
   The first response implicitly assumes that the program has been installed
in the DCL command tables. This provides complete parsing of the command
line with such features as making arguments default, required, optional or
any of the above depending on the presence of arguments given. The user has
complete freedom to create and or add to his own personal version of these
tables or to switch to the system default tables at any time. The interface
is quite straightforward and far more robust/capable than most Unix
programmers are willing to take the time to install.
   Of course their is nothing which prevents the VMS program from taking
the DCL command line and parsing its own arguments as per Unix.
   This is unfortunately one of the VMS strongpoints, and not really an
appropriate target for Unix flamers.

In article <1320@psivax.UUCP> friesen@psivax.UUCP (Stanley Friesen) writes:
    In article <873@rti-sel.UUCP> rcb@rti-sel.UUCP (Random) writes:
    >
    >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.
    
    	Oh, *great*:-) How does the DCL parse the arguments for a user
    written application program?? I can't see how it can do this without
    some rather messy interface requirements.  This really sounds like a
    way to make user-written programs second class citizens on the system.
    I think the individual program is better qualified to analyse its own
    arguments, whay is really needed is a *standard* for this, like getopts(3)!

Random isn't quite clear on this.  The program itself doesn't ever need to
look at the command line.  Instead, DCL does all of the parsing of the
command.  For an applications programmer, you deal with the "messy"
interface requirements by telling DCL what your command arguments should
look like via a command definition file.  Then, when you write your program,
you can ask DCL what the arguments were.  It's actually very clean and
neat...

It is standard, and it is the way that all of DEC's programs interface with
DCL.  It is definitely a first-class way to go.  Yes, it is complicated.
Yes, it provides more functionality than getopts(3).  Yes, there is a way to
bypass the whole mess and read the command line yourself (this, incidentaly,
is the second-class way to go).  Yes, it is standard.  No, the command
definition language is not all that messy.  It's actually quite cute, and
gets around a LOT of grunt programming.

Don't flame me, I don't read my mail.
-- 
Tony Li ;-)		Usc Computer Science
Uucp: ...!{{decvax,ucbvax}!sdcsvax,hplabs,allegra,trwrb}!sdcrdcf!uscvax!tli
Bitnet: tli@uscvaxq, tli@jaxom, tli@ramoth
Csnet: tli@usc-cse.csnet
Arpa: tli@usc-ecl.arpa

>
>        Oh, *great*:-) How does the DCL parse the arguments for a user
>written application program?? I can't see how it can do this without
>some rather messy interface requirements.  This really sounds like a
>way to make user-written programs second class citizens on the system.
>I think the individual program is better qualified to analyse its own
>arguments, whay is really needed is a *standard* for this, like getopts(3)!
>--
>
>                                Sarima (Stanley Friesen)
>
>UUCP: {ttidca|ihnp4|sdcrdcf|quad1|nrcvax|bellcore|logico}!psivax!friesen
>ARPA: ??
     
VMS allows *TWO* ways for an image (with parameters) to be activated.
If you so choose, you may have your application parse ALL of the
command line, spending tons of worthless cpu time deciding what is
right and what is wrong, or you can opt to have DCL parse the command
line for you.  In EITHER case, it is YOUR decision as to which
parameters or qualifiers are valid, etc.
     
In the first case, your program would make a call to a library
function called LIB$GET_FOREIGN(...)  and magically you would be
given everything typed past the command name.  From that point
on, it's your responsibility to parse the mess you get.
     
The other alternative is to write a "command definition" file
which describes EXACTLY to DCL what qualifiers or parameters
are valid, which ones can be use together, which ones require
a value, which ones have default values, etc..  Sounds pretty
powerful to me!  DCL will even PROMPT for missing parameters
with a prompt that YOU decide on!
     
All your program has to do then is to call special routines
to pick up this information.  For example, to get the value
of the qualifier "/REMOTE" all you would do is call a routine
called CLI$GET_VALUE('REMOTE'...)  Magically you get a string
returned which contains the "value" of the qualifier.
     
I don't see this interface as kludgy in any way, I consider
it an elegant interface to a complex parsing routine called
DCL.   For more on how this all works, check out the Command
Definition Utility in the Utilities Ref. Manual.  (You might
be surprised)
     
Ever considered checking the manuals BEFORE complaining about
this or that?
     
Cheers,
     
Tim Bieling, System Manager - Architecture Computer Lab
                              Penn State University
     
Bitnet:  Bieling@Psuarch
     

In article <1320@psivax.UUCP> friesen@psivax.UUCP (Stanley Friesen) writes:
>	Oh, *great*:-) How does the DCL parse the arguments for a user
>written application program?? I can't see how it can do this without
>some rather messy interface requirements.  This really sounds like a
>way to make user-written programs second class citizens on the system.
>I think the individual program is better qualified to analyse its own
>arguments, whay is really needed is a *standard* for this, like getopts(3)!

On the contrary, user-written programs under VMS are not second-class citizens
in this respect.  There is a fully documented facility for telling DCL how to
parse the command line.  This facility is used by system and user programs
alike.  As to whether it's better to have the program or the system parse the
command line, I think that's a matter of taste.  However, having the system
do the parsing makes it easier to encourage standardization.

In article <1320@psivax.UUCP>, friesen@psivax.UUCP (Stanley Friesen) writes:
>In article <873@rti-sel.UUCP> rcb@rti-sel.UUCP (Random) writes:
>>>Most Unix programs will print out a line or so of "usage" diagnostics if you
>>>invoke them with bogus arguments.  Do VMS programs do this?
>>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.
>        Oh, *great*:-) How does the DCL parse the arguments for a user
>written application program?? I can't see how it can do this without
>some rather messy interface requirements.  This really sounds like a
>way to make user-written programs second class citizens on the system.
>I think the individual program is better qualified to analyse its own
>arguments, whay is really needed is a *standard* for this, like getopts(3)!
>                                Sarima (Stanley Friesen)
>UUCP: {ttidca|ihnp4|sdcrdcf|quad1|nrcvax|bellcore|logico}!psivax!friesen
>ARPA: ??

To be fair, it is possible to set a user program up to receive command line
arguments which have been pre-parsed by DCL, but the procedure is indeed
slightly "messy" (special library functions must be called from the user
program, and DCL must be told explicitly (as in the login procedure) about
a file containing a description of how DCL is to parse the arguments,
qualifiers, etc. for user commands.  (It is also possible to set up a
user program as a "foreign" command, whereby it is defined as a "symbol"
[kind of like a ksh or csh "alias"] and an image of the command line can
be accessed through a special library function by the program thus invoked.)

However, even at best DCL "diagnostics" can be ambiguous.  For example,

$ SHOW USERS/BOGUS

gets me the diagnostic

%DCL-W-IVQUAL, unrecognized qualifier - check validity, spelling, and placement
 \BOGUS\

Hardly pointing out the specific problem!  Better something like this (under
System V):

$ who -bogus
who:  illegal option -- o
Usage:	who [-rbtpludAasHTq] [am i] [utmp_like_file]

r	run level
b	boot time
t	time changes
p	processes other than getty or users
l	login processes
u	useful information
d	dead processes
A	accounting information
a	all (rbtpludA options)
s	short form of who (no time since last output or pid)
H	print header
T	status of tty (+ writable, - not writable, x exclusive open, ? hung)
q	quick who
-- 
 -------------------------------    Disclaimer:  The views contained herein are
|       dan levy | yvel nad      |  my own and are not at all those of my em-
|         an engihacker @        |  ployer or the administrator of any computer
| at&t computer systems division |  upon which I may hack.
|        skokie, illinois        |
 --------------------------------   Path: ..!{akgua,homxb,ihnp4,ltuxa,mvuxa,
						vax135}!ttrdc!ttrda!levy

In article <1320@psivax.UUCP> friesen@psivax.UUCP (Stanley Friesen) writes:
>In article <873@rti-sel.UUCP> rcb@rti-sel.UUCP (Random) writes:
>>
>>>Most Unix programs will print out a line or so of "usage" diagnostics if you
>>>invoke them with bogus arguments.  Do VMS programs do this?
>>>
>>
>>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.
>
>	Oh, *great*:-) How does the DCL parse the arguments for a user
>written application program?? I can't see how it can do this without
>some rather messy interface requirements.  This really sounds like a
>way to make user-written programs second class citizens on the system.
>I think the individual program is better qualified to analyse its own
>arguments, whay is really needed is a *standard* for this, like getopts(3)!
>-- 
>				Sarima (Stanley Friesen)

Have you ever possibly considered finding out about something before
talking about. It will usually make you look a lot less like a fool.
The DCL command definitions simply define how many parameters can be used,
which ones are optional, the possible switches, The possible switch locations,
and the possible types for parameters and switches. It can also be used
to change the default values based on interactive or batch operation.
The possible types are simply string, number, file, acl, etc. and also
one of a list of user defined keywords. DCL is capable of parsing these
properly because you give it a definition that defines all these possibilities.
Also, one of the possibilities is type=rest_of_line which will turn off all
parsing and make the rest of the line be one parameter. The advantages it
gives you are that if you give it too many parameter, it give you an error
message. If you give it too few, it will prompt for what it needs. If a 
switch requires a value and you don't give it one, it will issue an error.
If a switch does not take a value and you giv it one, it will issue an error.
If you give a string to a parameter of type number you get an error message.
And if you use a switch that is not defined, you get an error. Beyond type
checking, it does not try to interpret your parameters and switch values.

An example of the definition file follows so that you might know what you
are maligning.


! The TeX command

define verb tex
	image tex_base:[programs]tex
	parameter p1, label=input_file
	parameter p2, label=second_file
	qualifier font_directory, label=font_area, nonnegatable, value(list)
	qualifier input_directory, label=input_area, nonnegatable, value(list)
	qualifier batch, batch


Simple, clean and easy to use. Definable on a per user basis, defined for
a group of users by the system manager or on a system wide basis. The program
interface is also clean. To get the values, you only have to issue the 
following call.

	call dcl$get_value ("input_area", string_variable)

and you have it. Easy, no? So, next time, ask someone about a feature you
know nothing about before you go shooting off your mouth (or keyboard).
-- 
					Random (Randy Buckland)
					Research Triangle Institute
					...!mcnc!rti-sel!rcb

In article <1320@psivax.UUCP> friesen@psivax.UUCP (Stanley Friesen) writes:
>>
>>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.
>
>	Oh, *great*:-) How does the DCL parse the arguments for a user
>written application program?? I can't see how it can do this without
>some rather messy interface requirements.  This really sounds like a
>way to make user-written programs second class citizens on the system.
>I think the individual program is better qualified to analyse its own
>arguments, whay is really needed is a *standard* for this, like getopts(3)!

Well I find its a very nice interface: 
 1 Define the syntax in a text form in a command definition file eg:
   DEFINE VERB CRASH
    IMAGE "USER_GAMES:DIE.EXE"
    PARAMETER P1,LABEL=TIME,VALUE(PROMPT="When?,TYPE=$DATETIME)
 2 Write your program and use two interface functions to check if 
   items are pressent and get their values, using the label to refer to them.
 3 Install the command by typing SET COMMAND filename - when and where you do this
   depends on who you want to see the definition.

 I like this because :
  All the prompting, syntax checks etc are done for you, it is possible to list
mutually exclusive options and have that checked too. Data type checks
can be specified - the example will only allow a valid date/time, and
will even convert CRASH TOMORROW into the real date for me!
The real winner is that it is the SAME parser for all commands. I 
have problems with any system that forces each program to parse its args
(CMS, NOS, UNIX...) - by all means use getopt, but who is going to rewrite
existing programs and manuals?

    -- 
Ian W Moor
  UUCP: seismo!mcvax!ukc!icdoc!iwm
  ARPA: iwm%icdoc@ucl                        
           
 Department of Computing   Whereat a great and far-off voice was heard, saying,
 Imperial College.         Poop-poop-poopy, and it was even so; and the days
 180 Queensgate            of Poopy Panda were long in the land.
 London SW7 Uk.         

In article <1320@psivax.UUCP>, friesen@psivax.UUCP (Stanley Friesen) writes:
> 	Oh, *great*:-) How does the DCL parse the arguments for a user
> written application program??

It's called SET COMMAND... you write a description of your command,
parameters, options, etc., including the runnable image name; and
give it to DCL.  Then you call a number of CLI$GETxxxx's for each
one.  Quite easy, in fact... I did it from Fortran.  I only wish
that the .CLD included documentation, and that HELP knew about the
DCL tables for such things as HELP xxx /PARAM.

I've been away from VMS for 3 years, and prefer Unix.  But let's
give VMS her due...

I mean, it used to be that you could say all kinds of dumb things
about VMS without any trouble.  But now, even a simple remark
on command line processing gets twenty answers from people who
actually know VMS.

You guys are taking all the fun out of USENET.

Cynically yours,

Martin Minow
decvax!minow

>
>However, even at best DCL "diagnostics" can be ambiguous.  For example,
>
>$ SHOW USERS/BOGUS
>
>gets me the diagnostic
>
>%DCL-W-IVQUAL, unrecognized qualifier - check validity, spelling, and placement
> \BOGUS\
>
>Hardly pointing out the specific problem!  Better something like this (under
>System V):

Seems reasonable to me. "/bogus" is unknown at that place. Could be in wrong
place or spelled wrong.

>
>$ who -bogus
>who:  illegal option -- o
>Usage:	who [-rbtpludAasHTq] [am i] [utmp_like_file]
>
>r	run level
>b	boot time
>t	time changes
>p	processes other than getty or users
>l	login processes
>u	useful information
>d	dead processes
>A	accounting information
>a	all (rbtpludA options)
>s	short form of who (no time since last output or pid)
>H	print header
>T	status of tty (+ writable, - not writable, x exclusive open, ? hung)
>q	quick who

I have NEVER seen a unix error message like this! At best I have seen

$ who -bogus
who:  illegal option -- o

or

$ who -bogus
Usage:	who [-rbtpludAasHTq] [am i] [utmp_like_file]

Of which I prefer the first as it at least tells me what I did wrong.

-- 
					Random (Randy Buckland)
					Research Triangle Institute
					...!mcnc!rti-sel!rcb

In article <6424QAA@PSUVM> QAA@PSUVM.BITNET writes:
>
>If you so choose, you may have your application parse ALL of the
>command line, spending tons of worthless cpu time deciding what is
>right and what is wrong, or you can opt to have DCL parse the command
>line for you.

In other words, you can spend tons or worthless CPU time, or you
can let DCL spend tons or worthless CPU time.  Or are you trying
to say that DCL can parse arguments without using CPU time?
--
Tim Smith                       USENET: sdcrdcf!ism780c!tim || ima!ism780!tim
"hey, bay-BEE'...hey, bay-BEE'" Compuserve: 72257,3706
                                Delphi || GEnie: mnementh

I apologise for the length of this, I cut it as much as posible.
Readers have to see the pro-UNIX posting (mildly sarcastic) and the
pro-VMS reply (rude and personal) to appreciate my answer about the
technical shortcomings of the answer.

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.
>>
	the somewhat sarcastic reply

>>	Oh, *great*:-) How does the DCL parse the arguments for a user
>>written application program?? I can't see how it can do this without
>>some rather messy interface requirements.  This really sounds like a
>>way to make user-written programs second class citizens on the system.
>>I think the individual program is better qualified to analyse its own
>>arguments, whay is really needed is a *standard* for this, like getopts(3)!
>>-- 
>>				Sarima (Stanley Friesen)
>
	the vituperative personal attack

>Have you ever possibly considered finding out about something before
>talking about. It will usually make you look a lot less like a fool.

	followed by a correct but incomplete technical rebuttal!

>The DCL command definitions simply define how many parameters can be used,
>which ones are optional, the possible switches, The possible switch locations,
>and the possible types for parameters and switches. It can also be used
>to change the default values based on interactive or batch operation.
>The possible types are simply string, number, file, acl, etc. and also
>one of a list of user defined keywords. DCL is capable of parsing these
>properly because you give it a definition that defines all these possibilities.
... another 30 lines or so of "simple" explanation deleted ...

No one in their right mind could consider this "simple".

>
>An example of the definition file follows so that you might know what you
>are maligning.
... 13 lines of more "simple" stuff deleted ... loaded with keywords ...
>Simple, clean and easy to use. Definable on a per user basis, defined for
>a group of users by the system manager or on a system wide basis. The program
			  ^^^^^^^^^^^^ That's convenient.

>interface is also clean. To get the values, you only have to issue the 
>following call.
>
>	call dcl$get_value ("input_area", string_variable)
>
>and you have it. Easy, no? So, next time, ask someone about a feature you
		  ^^^^^^^^^ in a word **NO**. To write a program asking
about the calling sequence instead of typing the command at the prompt
is not by any stretch of definition "easy".

>know nothing about before you go shooting off your mouth (or keyboard).
^^ more tact and courtesy ^^

What really made this answer so obnoxious is that after all this
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
     ^   ^ ^   ^       ^    ^    ^
     |   | |   |       |    |    |__ filename
     |   | |   |       |    |_______ subdirectory
     |   | |   |       |____________ user directory
     |   | |   |____________________ device (may be logical = directory)
     |   | |________________________ $ for binary, @ for DCL shell
     |   |__________________________ mystic assignment operator
     |______________________________ symbol now defined as valid command

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.

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.
-- 
	-bill davidsen

  ihnp4!seismo!rochester!steinmetz!--\
                                       \
                    unirot ------------->---> crdos1!davidsen
                          chinet ------/
         sixhub ---------------------/        (davidsen@ge-crd.ARPA)

"Stupidity, like virtue, is its own reward"

In article <859@kbsvax.steinmetz.UUCP> davidsen@kbsvax.UUCP (Davidsen) writes:
>What really made this answer so obnoxious is that after all this
>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
[Explanation of syntax deleted. It's like a Bourne shell variable
assignment, with `:==' replacing `='.]

You forgot what I considered the nicest feature of the VMS alias mechanism:

	$ r*edo:==<etc>

will make any prefix of "redo" down to "r" valid as a redo. Similarly,

	$ ch*eck:==<etc>

will make any prefix of "check" down to "ch" a valid as a check. Nice
feature, that. I just wish some Unix shell (ksh, preferably) had it.

>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.

I've used Unix since v6, and VMS since 1.5 or so, and they are both
only acceptable - and each only for some subset of all possible
applications. I do find the Unix interface more convenient, but I
found the response for small programs better on loaded systems under
VMS. Not sure why (but I have my suspicions), and of course the load &
configuration (and which version of what is running) are never the
same on those systems.

	<mike

In article <859@kbsvax.steinmetz.UUCP> davidsen@kbsvax.UUCP (Davidsen) writes:
[Much stuff deleted.]
    >interface is also clean. To get the values, you only have to issue the 
    >following call.
    >
    >	call dcl$get_value ("input_area", string_variable)
    >
    >and you have it. Easy, no? So, next time, ask someone about a feature you
    		  ^^^^^^^^^ in a word **NO**. To write a program asking
    about the calling sequence instead of typing the command at the prompt
    is not by any stretch of definition "easy".

This is not a program to ask about the calling sequence.  This is a call back 
to DCL to get the value of one of the parameters.  To translate, the above is
roughly eqivalent to:

	strcpy (string_variable, argv[INPUT_AREA]);
-- 
Tony Li ;-)		Usc Computer Science
Uucp: ...!{{decvax,ucbvax}!sdcsvax,hplabs,allegra,trwrb}!sdcrdcf!uscvax!tli
Bitnet: tli@uscvaxq, tli@jaxom, tli@ramoth
Csnet: tli@usc-cse.csnet
Arpa: tli@usc-ecl.arpa

In article <1065@jade.BERKELEY.EDU>, mwm@eris.berkeley.edu writes:
>You forgot what I considered the nicest feature of the VMS alias mechanism:
>
>	$ r*edo:==<etc>
>
>will make any prefix of "redo" down to "r" valid as a redo. Similarly,
>
>	$ ch*eck:==<etc>
>
>will make any prefix of "check" down to "ch" a valid as a check. Nice
>feature, that. I just wish some Unix shell (ksh, preferably) had it.
>

That might be a good idea, but you can also get this effect by using
ln to link the executable to entries by the shorter names, e.g.

ln /bin/who /bin/wh
ln /bin/crypt /bin/cryp; ln /bin/crypt /bin/cry; ln /bin/crypt /bin/cr;

(Which prompts another aside on VMS; why oh why is there a SET FILE/ENTRY
under VMS if DELETE-ing the extra entry blows away the file data itself,
leaving any other entries for that file invalid?  Why isn't a link count
kept a la the UNIX (TM of AT&T) OS even if VMS doesn't have inodes?)
-- 
 -------------------------------    Disclaimer:  The views contained herein are
|       dan levy | yvel nad      |  my own and are not at all those of my em-
|         an engihacker @        |  ployer or the administrator of any computer
| at&t computer systems division |  upon which I may hack.
|        skokie, illinois        |
 --------------------------------   Path: ..!{akgua,homxb,ihnp4,ltuxa,mvuxa,
	   go for it!  			allegra,ulysses,vax135}!ttrdc!levy

In article <1122@ttrdc.UUCP> levy@ttrdc.UUCP writes:
    (Which prompts another aside on VMS; why oh why is there a SET FILE/ENTRY
    under VMS if DELETE-ing the extra entry blows away the file data itself,
    leaving any other entries for that file invalid?  Why isn't a link count
    kept a la the UNIX (TM of AT&T) OS even if VMS doesn't have inodes?)

SET FILE/ENTRY in VMS is a serious kludge and is not meant to be used in cases
where one entry might be deleted.  There is no link count, and there are no
inodes to speak of.  There is an index to the system and the link count
could be kept there....  but it's not.  Basically, SET FILE/ENTRY is a very
dangerous feature which is not properly supported.


-- 
Tony Li ;-)		Usc Computer Science
Uucp: ...!{{decvax,ucbvax}!sdcsvax,hplabs,allegra,trwrb}!sdcrdcf!uscvax!tli
Bitnet: tli@uscvaxq, tli@jaxom, tli@ramoth
Csnet: tli@usc-cse.csnet
Arpa: tli@usc-ecl.arpa

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
________________________________________________________________________________

In article <1122@ttrdc.UUCP> levy@ttrdc.UUCP writes:
>(Which prompts another aside on VMS; why oh why is there a SET FILE/ENTRY
>under VMS if DELETE-ing the extra entry blows away the file data itself,
>leaving any other entries for that file invalid?  Why isn't a link count
>kept a la the UNIX (TM of AT&T) OS even if VMS doesn't have inodes?)

VMS does have the equivalent of inodes; they're blocks in the index
file, pointed to by the FID.  The index file looks very much like the
inode list of Unix.  It would take very little work to add a link
count to the index block and change $DELETE to Unix behavior.  There
are a couple of barriers to making the behavior identical -- for one
thing, the filename (but not the directory name) is stored in the
index block, but this is mostly relevant when a lost file is
recovered (because, say, a user blew away a directory entry with SET
FILE/REMOVE).  But VMS could handle links properly without that much
effort, and users wouldn't notice the change.
-- 
- Joe Buck 	{ihnp4!pesnta,oliveb,nsc!csi}!epimass!jbuck
  Entropic Processing, Inc., Cupertino, California