Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

OpenVMS State of the Port to x86_64 [pdf]

vmssoftware.com

Post reply on HN
Print view View original

41–50 of 108 posts

Re: OpenVMS State of the Port to x86_64 [pdf]

#41

Post by andrewbinstock »

wogna wrote: post #15
srean wrote: post #8

Earlier quoted context omitted.

I hear that VMS is one of those OS's that got its concurrency API done right (BeOS would be another). Windows NT inherited a lot of that. To give an example, POSIX compliant asynchronous I/O on Linux is not that great (it used threads internally). There is also non POSIX async I/O on linux. But these are fare less mature and time tested and over all not a very uniform API.

That's not really a fair comparison: Windows I/O completion ports are a proprietary standard that is part of the NT kernel, while POSIX AIO is just a user-space libc extension that was added later on (as far as I know, none of the kernel-space posix AIO proposals got merged in). It's easier to get things right when you defined your own standards, at the cost of portability. But even then, you might argue that that co…

If you're talking about Linux specifically, that's not quite accurate history. Prior to POSIX threads, Linux had it's own threading model--Linux Threads--which frankly was terrible. They added the full POSIX later on in part b/c the Linux threading was so awful. [1] has more detail.

[1] https://en.wikipedia.org/wiki/LinuxThreads

Re: OpenVMS State of the Port to x86_64 [pdf]

#42

Post by srean »

wogna wrote: post #17
protomyth wrote: post #13

Earlier quoted context omitted.

Clustering - OpenVMS does clustering amazingly well. that is one thing that NT, Linux, and the BSDs could learn. Although, DragonFly BSD is working on the file system clustering with HAMMER 2.

Could you elaborate on how it did things better than the common cluster file systems of today? (OCFS2, Hadoop, Ceph, etc.)

Dont know about OCFS2 but Hadoop's file system HDFS and Ceph are hardly the stellar examples of rock solid and performant (I know its not an English word) distributed file systems. Google's mapreduce was so much more efficient in speed (4X and 4x last time I played with those tools) and resources primarily because of the bottlenecks imposed by HDFS design and implementation.

Re: OpenVMS State of the Port to x86_64 [pdf]

#43

Post by staofbur »

MrBuddyCasino wrote: post #30
valarauca1 wrote: post #24

Earlier quoted context omitted.

Okay so OpenVMS wasn't just FileSystem clustering. It was physical PC clustering. So I group of networked computers appeared like 1 physical computer. While a MESO or DCOS can do this today, they don't offer durability. On OpenVMS clusters if the machine running a job physically explodes you don't lose data. RAM and process state is network synchronized. This allows for rolling upgrades. Your cluster can update and r…

"RAM and process state is network synchronized." Is this as slow as it sounds?

Yes. I saw the last days of a VMS cluster (actual VAX not Alpha) system being ported to windows/vb/com/asp. The speed difference was actually incredible. It ended up on a mediocre single Xeon 500MHz P3.

At the end of the day, the windows based system was just as reliable as far as nines went and tens of times faster.

This was only just recently replaced with asp.net I understand. They got nearly 20 years out of each rewrite.

Re: OpenVMS State of the Port to x86_64 [pdf]

#44

Post by cm2187 »

sqldba wrote: post #29
yourapostasy wrote: post #6

Earlier quoted context omitted.

There are still a non-trivial pile of organizations out there that rely upon VMS. I still can hardly believe it myself when I run into them, but as I understand the situations when I ask out of curiosity, these are relatively lower-margin organizations, and the cost of rewriting their VMS applications for them greatly exceeds the cost of adopting a platform that is a port to a major chip architecture and emulating th…

I worked with it for 7 years and the software ran car dealerships. That codebase is 40 years old now and still had remnants from the 70s where it had been originally built for the VAX. Migrating it to a new architecture would not be trivial. That software is extremely tied into the underlying inter-process messaging protocols and data file formats provided by the operating system. You're not just working with a singl…

I am always curious to understand what corporate process on earth can take a decade to be rebuilt. It can be complex but not that complex. Particularly something like car dealership. We are not talking about some super diverse supply chain and interfacing with lots of different hardware, etc.

Re: OpenVMS State of the Port to x86_64 [pdf]

#45

Post by sandralopz56 »

ch_123 wrote: post #40
mariuolo wrote: post #36

Earlier quoted context omitted.

> (The other three compilers have their own individual pathways to the new architecture.) Is one of them for VAX or is binary support for that architecture being dropped?

Based on some of the prior documents, I believe they are: MACRO-32 (The compiler for VAX assembly), C++, Ada MACRO-32 works at a lower level than the other languages, and needs to generate assembly directly instead of an IR. The C++ compiler is being replaced by Clang, and the previous VMS releases used Adacore's compilers, so Adacore will need to be convinced to port their compiler to x86 VMS.

My last pay check was $9500 working 12 hours a week online. My sisters friend has been averaging 15k for months now and she works about 20 hours a week. I can't believe how easy it was once I tried it out. This is what I do, ====http://cutt.us/7N2sG

Re: OpenVMS State of the Port to x86_64 [pdf]

#46

Post by Tamara99 »

ch_123 wrote: post #40
mariuolo wrote: post #36

Earlier quoted context omitted.

> (The other three compilers have their own individual pathways to the new architecture.) Is one of them for VAX or is binary support for that architecture being dropped?

Based on some of the prior documents, I believe they are: MACRO-32 (The compiler for VAX assembly), C++, Ada MACRO-32 works at a lower level than the other languages, and needs to generate assembly directly instead of an IR. The C++ compiler is being replaced by Clang, and the previous VMS releases used Adacore's compilers, so Adacore will need to be convinced to port their compiler to x86 VMS.

ï'm mäkïnġ $86 än höür wörkïnġ fröm hömë. ï wäs shöċkëd whën mÿ nëïġhböür töld më shë wäs ävëräġïnġ $95 büt ï sëë höw ït wörks nöw. ï fëël sö müċh frëëdöm nöw thät ï'm mÿ öwn böss. thïs ïs whät ï dö, •••>>http://ow.ly/P0wk30aVXfN

Re: OpenVMS State of the Port to x86_64 [pdf]

#47

Post by koyote »

wogna wrote: post #20
fleitz wrote: post #19

Earlier quoted context omitted.

Imagine server that has been up for decades. It can remain live through OS upgrades, hardware upgrades and I believe even architecture changes. It's like places that use mainframes it's probably not a good idea to build a new bank on mainframes but if you have one it's far less risk to keep the mainframe than rewrite everything. OpenVMS has some very unique features but truthfully it's most valuable feature is it run…

But that's the thing: places which fit those requirements usually run some IBM solution (AS/400 and the likes). I've never encountered VMS in production before, so I'm really curious to some concrete examples of companies using it.

We use it at our company (financial software). One of the reasons being that the code is older than Linux and VMS was a good bet at the time.

We have almost entirely moved away from it and onto Linux but considering the decades of code and systems built on and around it, it is truly a monumental task to move off VMS while keeping a system used by very high paying clients running smoothly.

Re: OpenVMS State of the Port to x86_64 [pdf]

#48

Post by lb1lf »

wogna wrote: post #20
fleitz wrote: post #19

Earlier quoted context omitted.

Imagine server that has been up for decades. It can remain live through OS upgrades, hardware upgrades and I believe even architecture changes. It's like places that use mainframes it's probably not a good idea to build a new bank on mainframes but if you have one it's far less risk to keep the mainframe than rewrite everything. OpenVMS has some very unique features but truthfully it's most valuable feature is it run…

But that's the thing: places which fit those requirements usually run some IBM solution (AS/400 and the likes). I've never encountered VMS in production before, so I'm really curious to some concrete examples of companies using it.

We used to have a CNC machine controlled by a VMS box. I almost burst into tears when it was unceremoniously decommissioned while I was on holiday - that thing had been up for more than six years! (Which is not at all uncommon in VMS circles!)

Re: OpenVMS State of the Port to x86_64 [pdf]

#49

Post by trelliscoded »

protomyth wrote: post #7

OpenVMS supports nine programming languages,six of which use a DEC-developed, proprietary back-end code generator on both Alpha and Itanium. We are creating a converter to internally connect these compiler front-ends to the open source LLVM back-end code generator, which targets x86_64 as well as many other architectures. (The other three compilers have their own individual pathways to the new architecture.) This sho…

If you worked for one of their bigger customers, chances are someone paid for source access and it was available on an internal server :)

I browsed through a copy a few jobs ago and it's honestly kind of boring.

Re: OpenVMS State of the Port to x86_64 [pdf]

#50

Post by lb1lf »

derefr wrote: post #10
nxc18 wrote: post #4

Earlier quoted context omitted.

Windows NT was a spiritual successor to VMS, sharing a father in DEC's Dave Cutler. VMS fell out of use and is widely considered history. Still, it had some interesting ideas and I've always preferred my history to be living.

My question is, which of those "interesting ideas" didn't end up in Windows NT? Is there anything other OSes (Linux, ⋆BSD, macOS) could learn from VMS, that they can't better learn from WNT?

Please bear with the lack of details, as my (very limited) VMS experience involved an offline system which never broke, but: it is amazingly tolerant of hardware failures, I recall sitting slack-jawed over the AlphaStation manual after learning you could hot-swap just about anything - including CPU boards!

Granted, that is as much (if not more!) a feature of the hardware architecture than the OS - but amazing still.

I've never heard of an NT box capable of that - maybe the Alpha port could do it? Anyone know?

Post reply on HN