Re: V7: VMS or UNIX ?

In article <31F091A7.6BA8_at_inmind.com> "Michael E. Austin" <austin_at_inmind.com> writes:
>It seems that someone took a rabbit trail on the different syntax
>between UNIX and OPENVMS. I will 'attempt' to give you some reasons
>for one or the other. (And throw my $.02 worth in on the 'openness' of VMS)
>
>
>I have used a number of different OS's including VMS (VAX, ALHPA and OPEN),
>NT, many flavors of UNIX including DYNIX (Sequent box), SCO Unix, Digital
>Unix (including Ultrix, and OSF/1=DEC-UNIX) SCO Unix, UNIXWARE and LINUX and
>HP UX. The question really has to do with: What are the system availability
>requirments for the application 8x5? 24x7? I have not EVER seen a unix
>box that had a 24x7 i/o intensive database application that could stay up

Well, I know of at least one AIX box that is 24x7. Not that I've seen it personally...

>and running more than 30 days at a time. Conversely, I have seen MANY VAX
>and ALPHA's running (Open)VMS that been up for 200+ days. and a few that
>have been up for 1100+ days. Just in case you need help, that means that they
>have not been rebooted in 3+years Most are not rebooted except a) when a
>device fails and needs to be replace, or b) when they take a serious
>power hit.

I've noticed we've taken power hits more often than unix crashes over the last couple of years. The unix come up way faster than the clusters.

>
>Configuring a CLUSTER is much easier than trying to figure out how to
>mirror the db on multiple systems. It is getting there, but the one thing

Only with adequate training - and that may be quite arguable with the disparity of training. A lot of DEC types vanished over the last few years.

>the current UNIX boxes cannot guarantee READ consistency across multiple
>systems. VMS + CLUSTER can!
>
>My overall reason for picking VMS over UNIX is stability & reliability (when
>the system crashes (if it ever does...) you usually don't have to pray that
>the filesystem didn't get corrupted causing you days of work to restore.)

Agree with this, certainly.

>
>Now, on the comment ( Open (HA!) VMS). Open VMS is one of only 3 OS's that
>has achieved the Xopen XPG4 rating. If you code to the POSIX standard, the
>code cna be very easily ported to other platforms. However, in my book, the
>only truly OPEN platform is DOS and the PC. You CANNOT just copy your code
>from one unix to another and have it work, most times, you can't even
>re-compile without making changes. And you call that OPEN? BTW if you

Semantics arguments that you seem to have a strange definition of "truly open" aside, implicit is the idea that the systems work. DOS/PC's crash all the time, they simply do not work predictably (extremely simple configurations aside, and notwithstanding).

Many software packages have the proper makes to recompile without making changes. The ones that don't, haven't been ported yet. I've seen things need changes between Alpha and Vax versions of VMS, so you can hardly make that argument. Just because something is coded specific to a version doesn't mean it isn't open.

>are running on a VMS system with POSIX installed, you can use unix-like
>syntax to do whatever. (and if you are real desperate, you can edit your
>LOGIN.COM file (ie. .login) and add symbols for ALL your unix commands:
>
>ls-la (note no space) :== DIR/DATE/SIZE
>ls :== DIR
>cd :== "SET DEFAULT "
>type :== type/page !this is equal to type|more

I've personally avoided this, because our customers likely don't have it defined, or the unix converse. I would recommend anyone learn the native mode of the system they have to work on, because even if you have complete control of your current environment, you may have to work in an environment you don't control in the future.

>
>Oh, and if you want to find a command that you have no clue what it is,
>but you know what it is you are looking for, ie (I want to search a file
>for a text string) If you type HELP at the prompt, it will not take you
>years to figure out that the command you are looking for is SEARCH. Imagine
>that!! grep?? awk?? sounds like someone trying to toss their cookies!
>You want to see what the memory looks like, try SHOW MEMORY, in other words
>it is VERY intuitive. Not what is the most obsure two or three characters
>I can name this command.

I strongly disagree with this statement, having gone through that thread before, will leave it at that. I will say that having a book by Aho, Weinberger and Kernighan above your desk helps, and one uses grep so much for so many useful things (and a lot easier than VMS search), that there is no need to know the actual acronym. Having funny words even helps some to remember them. I learned VMS first, so even being prejudiced toward it initially, I can see the unix way of problem reduction is superior to the VMS way of project engineering, for most things. Not that every part of unix is written the unix way, in fact that is its biggest problem. But first, you have to learn the unix way. Then you see solutions, instead of problems.

>
>hope this is useful...
>
>
>
>
>Graham Miller wrote:
>>
>> hi,
>> Relative directories in VMS (and OpenVMS) are:
>>
>> set def [.<Next Level Down>]
>> .
>.
>.
>bunch of stuff ommited...
>.
>.
>.
>>
>> >*does* have a VMS equivalent...
 

>> >$ set def [.nextdirdown]
 

>> >(note the full stop after the first square bracket).
 

>> >"set def" stands for SET DEFAULT. The general idea is a subtle
>> >difference from the Unix way of thinking. In Unix "cd" means "change
>> >directory" or "move me from where I am now into another direcory". In
>> >VMS "set def" means "set default" or "tell the O/S where to look for
>> >files if I don't stick a path on the front.
 

>> >It's a subtle distinction and the only real "difference" is that if
>> >you SET DEF to a non-existent directory, you will only get an error
>> >message if you try to access a file in that directory.
 

>> >Well, I hope that this is clearer than it looks to me! :-)
 

>> >Pete
 

>> >--
>> >Peter Moore.
>> >DBA, IS Ops,
>> >Sequent Computer Systems Ltd, Weybridge, UK.
>
>--
>==============================
>* Michael E. Austin *
>* austin_at_inmind.com *
>==============================
>

-- 
Joel Garry               joelga_at_rossinc.com               Compuserve 70661,1534
These are my opinions, not necessarily those of Ross Systems, Inc.   <> <>
%DCL-W-SOFTONEDGEDONTPUSH, Software On Edge - Don't Push.            \ V /
panic: ifree: freeing free inodes...                                   O