8 ms·

Excuse my ignorance on this topic, but what exactly can you do with OpenVMS that you cannot do with a FreeBSD, Linux, or even Windows server? What's the specifi

by mikece 7y ago

Excuse my ignorance on this topic, but what exactly can you do with OpenVMS that you cannot do with a FreeBSD, Linux, or even Windows server? What's the specific advantage of OpenVMS?

jotm 7y ago
I'm guessing run one of the mentioned HP servers/mainframes?
imglorp 7y ago
You can run other OSs on that hardware, but VMS is an alien artifact that still has things to learn from and widen our scope. For example, I/O redirection: https://saf.bio.caltech.edu/vms_beginners_faq.html#PROC077 https://saf.bio.caltech.edu/vms_beginners_faq.html#PROC077
- monocasa 7y ago
  Unix has had IO redirection longer than VMS.
- asveikau 7y ago
  > This must be done before the program runs I have no experience with VMS, but I always thought a similar limitation was weird on Windows. On Unix you can replace an active descriptor with dup2(2). On windows, whatever HANDLEs you have at CreateProcess you are stuck with forever. You can replace the CRT's integer descriptor or SetStdHandle, maybe they have freopen these days too, but these are usernode abstractions. Sometimes I would like to swap the kernel structure backing a HANDLE after it's created.
  - JoshTriplett 7y ago
    You do have to take care if you're replacing a handle underneath an active program even with dup2, though. The file descriptor replacement is atomic, but higher-level code in the process (such as struct FILE in libc, or similar in other languages) may have buffers that it hasn't finished flushing yet.
    - asveikau 7y ago
      True, so you fflush before dup2. Not having dup2 is annoying though. With win32 you cannot make the change automatically propagate to child processes. You need to specify the handles in every CreateProcess call. Sometimes that happens deep inside a library and you can't modify it.
      - JoshTriplett 7y ago
        > True, so you fflush before dup2. Assuming you know exactly what buffering everything in the process does. But you just mentioned a case of something that "happens deep inside a library". I absolutely agree that dup2 should be possible; I only mentioned that replacing a "live" file descriptor isn't necessarily simple (unless your program is currently quiesced).
        asveikau 7y ago
        > But you just mentioned a case of something that "happens deep inside a library". Well, if we're talking C, if you have the same libc as all your libraries [not true on Win32, but true on recent popular Unix-like OSs], you should be able to safely fflush and dup2, then call into any applicable library code ... But anyway, I think the difficulties with it are much larger in the kernel than in user land. I could very well imagine a scenario in which supporting dup2(2) required more locking and reference counting of kernel objects. I.e. any kernel thread currently operating against the data structure backing a descriptor must have that operation survive a dup2.
  - int_19h 7y ago
    freopen() has been around and working as intended on Win32 for ages. And this works for all userspace in the same process (i.e. it's not just FILE* that gets redirected, but everything going to stdout regardless of how it gets there). So I'm not sure why the kernel side of it would matter? dup2() is there as well: https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/dup-dup2?view=vs-2019 https://docs.microsoft.com/en-us/cpp/c-runtime-library/refer...
bitwize 7y ago
OpenVMS has real asynchronous I/O supported directly by the kernel. Under Linux, all I/O is synchronous but possibly nonblocking, and all disk I/O is blocking. OpenVMS also has a comprehensive, fine-grained security model involving a database of subjects, actions, and objects, giving administrators fine control over who may do what to what. In short, ACLs built into the OS from the ground up. In Linux, ACLs are a bag on the side; their inclusion in BSDs varies. OpenVMS also automatically logs all events, providing an audit trail for security incidents. OpenVMS clusters easily (called a VAXcluster in the VAX days); support for failover and load balancing is built into the OS. OpenVMS's command line interface is designed around a mistake-prone operator who hasn't had their coffee. It doesn't have, say, the 'rm -rf /' problem. Unix's CLI assumes a perfect operator who gets everything right the first time. "Fat fingering" a command could have disastrous consequences; in most cases on VMS, the command interpreter will raise a syntax error. OpenVMS also has file versioning built into the file system; again, this is a bag on the side (formerly: SCCS/RCS, today: git) in Unix. Oh, and OpenVMS doesn't crash. Like, ever. Windows Server has some of these features. The NT kernel has the same designer as VMS -- Dave Cutler, a man whose contempt for the Unix design philosophy is well documented.
- eej71 7y ago
  OpenVMS absolutely does crash. I was actively involved with a very large cluster - and with enough abuse - individual nodes will tip over - and if you aren't careful - you can take down an entire cluster. It was an interesting OS. Some different ideas in there. But the idea that it never crashes is simply false.
  - technofiend 7y ago
    Anecdotally, VMS had a command to exclusively allocate resources which I learned on a predecessor OS RSTS/E. Predecessor in the sense that some command syntax carried over; I have no clue how much RSTS/E source if any made its way into VMS. Regardless, the idea was you would ALLOC the line printer or tape drive to prevent anyone else from stepping on you. At Digital's NCC booth in 1981 or 1982 (I forget) they were showing off clustered VAXes with the nodes named after colors. I jokingly typed ALLOC RED:: and discovered that allocating an entire node to yourself crashed the cluster.
grandinj 7y ago
It had lovely first-class support for batch queues, local and distributed, with load balancing, quotas, forwarding, etc, which you still cannot get on a Linux system. It had great shared/cluster filesystems, that came standard, that have only been replicated in about the last 5 years in Linux (see Gluster/Ceph/etc), and the Linux equivalents are (still!) less well documented with much higher admin overhead. The downside was, of course, that all those great features worked only with VMS software and hardware, and only with specific combinations of the above.
numpad0 7y ago
I take it as diversity thing. Everything is so alien to Windows-GNU-Linux mental model. Not sure if there’s any immediate value to it but fossils of dinosaurs tells us what we did right or wrong.
csours 7y ago
Someone may correct me if I'm wrong, but I think OpenVMS is used for real time testing of embedded controllers, for instance automotive computer modules.
icedchai 7y ago
I'll just say that it's fun to play around with... something different. It's like an alternate dimension. One of the first multi-user machines I worked on, back in the late 80's, was a VAX running VMS so I have fond memories of it.
pjmlp 7y ago
Use an almost memory safe for systems programming (BLISS) for example (from the point of view of ALGOL linage). While it kind of applies to Windows with C++/.NET Native, UNIX clones are relatively far from it. Although Apple and Google's forks are also moving into that direction. Then the OS is relatively quite robust, there are several histories of uptimes measured in years with VMS systems.
bitminer 7y ago
You can run elderly software that was written for it. At one point there was a paid app on Android that ran a VAX emulator. (A port of simh I think.) A 1GHz phone ran the emulator faster than any real VAX ever was. I once offered to set up a copy of an old corporate accounting "app" on said emulator for our accounting dept. (They occasionally needed to refer to old reports still available on the old VAX system.). On the chief accountant's own phone. He said no.

by mikece 7y ago

Excuse my ignorance on this topic, but what exactly can you do with OpenVMS that you cannot do with a FreeBSD, Linux, or even Windows server? What's the specific advantage of OpenVMS?

jotm 7y ago

I'm guessing run one of the mentioned HP servers/mainframes?

imglorp 7y ago

You can run other OSs on that hardware, but VMS is an alien artifact that still has things to learn from and widen our scope. For example, I/O redirection: https://saf.bio.caltech.edu/vms_beginners_faq.html#PROC077 https://saf.bio.caltech.edu/vms_beginners_faq.html#PROC077

monocasa 7y ago
Unix has had IO redirection longer than VMS.
asveikau 7y ago
> This must be done before the program runs I have no experience with VMS, but I always thought a similar limitation was weird on Windows. On Unix you can replace an active descriptor with dup2(2). On windows, whatever HANDLEs you have at CreateProcess you are stuck with forever. You can replace the CRT's integer descriptor or SetStdHandle, maybe they have freopen these days too, but these are usernode abstractions. Sometimes I would like to swap the kernel structure backing a HANDLE after it's created.
- JoshTriplett 7y ago
  You do have to take care if you're replacing a handle underneath an active program even with dup2, though. The file descriptor replacement is atomic, but higher-level code in the process (such as struct FILE in libc, or similar in other languages) may have buffers that it hasn't finished flushing yet.
  - asveikau 7y ago
    True, so you fflush before dup2. Not having dup2 is annoying though. With win32 you cannot make the change automatically propagate to child processes. You need to specify the handles in every CreateProcess call. Sometimes that happens deep inside a library and you can't modify it.
    - JoshTriplett 7y ago
      > True, so you fflush before dup2. Assuming you know exactly what buffering everything in the process does. But you just mentioned a case of something that "happens deep inside a library". I absolutely agree that dup2 should be possible; I only mentioned that replacing a "live" file descriptor isn't necessarily simple (unless your program is currently quiesced).
      - asveikau 7y ago
        > But you just mentioned a case of something that "happens deep inside a library". Well, if we're talking C, if you have the same libc as all your libraries [not true on Win32, but true on recent popular Unix-like OSs], you should be able to safely fflush and dup2, then call into any applicable library code ... But anyway, I think the difficulties with it are much larger in the kernel than in user land. I could very well imagine a scenario in which supporting dup2(2) required more locking and reference counting of kernel objects. I.e. any kernel thread currently operating against the data structure backing a descriptor must have that operation survive a dup2.
- int_19h 7y ago
  freopen() has been around and working as intended on Win32 for ages. And this works for all userspace in the same process (i.e. it's not just FILE* that gets redirected, but everything going to stdout regardless of how it gets there). So I'm not sure why the kernel side of it would matter? dup2() is there as well: https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/dup-dup2?view=vs-2019 https://docs.microsoft.com/en-us/cpp/c-runtime-library/refer...

bitwize 7y ago

OpenVMS has real asynchronous I/O supported directly by the kernel. Under Linux, all I/O is synchronous but possibly nonblocking, and all disk I/O is blocking. OpenVMS also has a comprehensive, fine-grained security model involving a database of subjects, actions, and objects, giving administrators fine control over who may do what to what. In short, ACLs built into the OS from the ground up. In Linux, ACLs are a bag on the side; their inclusion in BSDs varies. OpenVMS also automatically logs all events, providing an audit trail for security incidents. OpenVMS clusters easily (called a VAXcluster in the VAX days); support for failover and load balancing is built into the OS. OpenVMS's command line interface is designed around a mistake-prone operator who hasn't had their coffee. It doesn't have, say, the 'rm -rf /' problem. Unix's CLI assumes a perfect operator who gets everything right the first time. "Fat fingering" a command could have disastrous consequences; in most cases on VMS, the command interpreter will raise a syntax error. OpenVMS also has file versioning built into the file system; again, this is a bag on the side (formerly: SCCS/RCS, today: git) in Unix. Oh, and OpenVMS doesn't crash. Like, ever. Windows Server has some of these features. The NT kernel has the same designer as VMS -- Dave Cutler, a man whose contempt for the Unix design philosophy is well documented.

eej71 7y ago
OpenVMS absolutely does crash. I was actively involved with a very large cluster - and with enough abuse - individual nodes will tip over - and if you aren't careful - you can take down an entire cluster. It was an interesting OS. Some different ideas in there. But the idea that it never crashes is simply false.
- technofiend 7y ago
  Anecdotally, VMS had a command to exclusively allocate resources which I learned on a predecessor OS RSTS/E. Predecessor in the sense that some command syntax carried over; I have no clue how much RSTS/E source if any made its way into VMS. Regardless, the idea was you would ALLOC the line printer or tape drive to prevent anyone else from stepping on you. At Digital's NCC booth in 1981 or 1982 (I forget) they were showing off clustered VAXes with the nodes named after colors. I jokingly typed ALLOC RED:: and discovered that allocating an entire node to yourself crashed the cluster.

grandinj 7y ago

It had lovely first-class support for batch queues, local and distributed, with load balancing, quotas, forwarding, etc, which you still cannot get on a Linux system. It had great shared/cluster filesystems, that came standard, that have only been replicated in about the last 5 years in Linux (see Gluster/Ceph/etc), and the Linux equivalents are (still!) less well documented with much higher admin overhead. The downside was, of course, that all those great features worked only with VMS software and hardware, and only with specific combinations of the above.

numpad0 7y ago

I take it as diversity thing. Everything is so alien to Windows-GNU-Linux mental model. Not sure if there’s any immediate value to it but fossils of dinosaurs tells us what we did right or wrong.

csours 7y ago

Someone may correct me if I'm wrong, but I think OpenVMS is used for real time testing of embedded controllers, for instance automotive computer modules.

icedchai 7y ago

I'll just say that it's fun to play around with... something different. It's like an alternate dimension. One of the first multi-user machines I worked on, back in the late 80's, was a VAX running VMS so I have fond memories of it.

pjmlp 7y ago

Use an almost memory safe for systems programming (BLISS) for example (from the point of view of ALGOL linage). While it kind of applies to Windows with C++/.NET Native, UNIX clones are relatively far from it. Although Apple and Google's forks are also moving into that direction. Then the OS is relatively quite robust, there are several histories of uptimes measured in years with VMS systems.

bitminer 7y ago

You can run elderly software that was written for it. At one point there was a paid app on Android that ran a VAX emulator. (A port of simh I think.) A 1GHz phone ran the emulator faster than any real VAX ever was. I once offered to set up a copy of an old corporate accounting "app" on said emulator for our accounting dept. (They occasionally needed to refer to old reports still available on the old VAX system.). On the chief accountant's own phone. He said no.