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

101–108 of 108 posts

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

#101

Post by bbatha »

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.

I haven't used other mainframe solutions, but one of my favorite features of VMS is logicals. Logicals are environment variables backed by a clustered key value store that's safe to use for distributed locks. Logicals appear to your process in a hierarchy of tables that inherit from one another, by default you have: job (shell subprocess) > process (shell session) > user > group > system (node) > cluster. You can also build your own tables stored with which ever chosen locality (system, cluster, etc) in the hierarchy. Meaning if you follow "12-factor" design, well it didn't have fancy name then, you could do things change configuration cluster wide in an instant.

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

#102

Post by staofbur »

cat199 wrote: post #74
staofbur wrote: post #43

Earlier quoted context omitted.

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…

You're confusing hardware speed with the software/IPC measurement - the fastest VAX machine ever made ran at 100Mhz (or maybe 120), with 10Mbit ethernet and SCSI-2 I/O paths (1MB/s on a disk or so). If you found a 486/100 and compared raw compute speed, the vax would likely have won for most cases, because it has 4x the registers. I'm not actually sure about the clustering IPC performance, but you are essentially com…

Not quite. We scaled it to 50x the user count at the same time.

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

#103

Post by seasoned_geek »

For those who have never heard of OpenVMS they might want to get themselves a copy of this book:

http://theminimumyouneedtoknow.com/app_book.html

VMS was the OS of choice when it posolutely absitively had to work. It was even banned from the Black Hat conferences because it never gave up the flag. THEN they started adding OpenSource components and it became just as insecure and unstable as Windows and Linux. It is now, once again welcomed at Black Hat conferences because every piece of OpenSource on it is the same 8-lane wide security breach the other platforms have.

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

#104

Post by seasoned_geek »

iamcamiel wrote: post #95
ch_123 wrote: post #40

Earlier quoted context omitted.

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.

Close. Macro-32 on x86 will use a lower-level interface to the same LLVM backend used by the other languages.

Adding more OpenSource to OpenVMS is __NOT__ a good thing. Especially adding it at the compiler level.

Moving to a common back end, especially for BASIC, would be a truly wretched decision. It would also be the final nail in the coffin of the interactive BASIC environment which VAX had and the industry begged for on Alpha. When it to the Itanium (Itanic) hardware we were all too busy begging for a processor that wouldn't combust like Samsung Galaxy or one of those hoverboards.

The interactive BASIC environment wasn't just for students. It provided a great sandbox to test out algorithms quickly, much like today's script kiddies would call a modern IDE.

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

#105

Post by seasoned_geek »

yourapostasy wrote: post #6
lallysingh wrote: post #2

Who, and why?

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…

To some extent this is true. One, used to be Fortune 50 but now probably not even Fortune 1000 famous corporation has been "going to replace TOLAS on OpenVMS" for the past 20+ years. Every attempt, without exception, has failed spectacularly. Now every attempt will fail because everyone who knew the business rules which went into the code modifications is either retired or dead. If management decided to "just pull the plug" and install some worthless Oracle or SAP or (insert big named software package here) the lawsuits for contract violations would bankrupt the company 5 times over.

Despite _constant_ denial by a good many people who claim to be "in the know" OpenVMS is still heavily used by defense contractors and various Homeland Security/DOD groups. Once you purge _all_ OpenSource from it the OS really is rock solid and secure.

During the time around the Bejing (sp?) Olympics, the largest and most modern Chinese steel mill was being designed and scheduled to be built after the games. The came to America for a custom control system written in FORTRAN running on OpenVMS. I know because I architected it.

A certain very famous brewer of dark beer in Ireland supposedly uses it to make their tasty beverages.

Most steel and paper mills around the world run OpenVMS for process control. A large number of nuclear power plants as well.

Putting it bluntly. OpenVMS, with _all_ OpenSource removed, is the OS humans bet the species on each and every day.

If you want to read a novella which has a big section discussion what happens when OpenVMS suddenly doesn't exist you should read this:

http://lesedi.us/

It's the middle book of the "Earth That Was" trilogy.

Infinite Exposure Lesedi - The Greatest Lie Ever Told John Smith - Last Known Survivor of the Microsoft Wars

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

#106

Post by seasoned_geek »

cm2187 wrote: post #44
sqldba wrote: post #29

Earlier quoted context omitted.

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.

It takes a minimum of 7 years to design from scratch, develop, test then settle in a "simple" customized order and inventory processing system, sans a WMS and picking component.

The "services" people subscribe to when setting up some kind of shopping cart on their Web site are neither complex nor highly customizable. Most importantly, they offer no opportunity what-so-ever to purchase a guaranteed delivery + guaranteed execution service.

When an order from a dealer (doesn't matter what automotive area) leaves their Business System, it is no longer their responsibility. It is the responsibility of the badge (Freightliner, Harley, Toyota, etc.) That order, which can be hundreds of thousands of dollars each and every day, must completely pass through the badge system, routing out to warehouses, vendors, distributors and manufacturing schedules, without ever being lost no matter what fails.

This is a completely different business model than Criminal-Net sales where people complain about the billions of dollars worth of "abandoned shopping carts" each year. By and large these are not "abandoned shopping carts." These are the symptom of a poorly designed system built with feeble tools. Something FAILED and the consumer went to a different site to place their order.

Blade and rack mount servers are built with inferior hardware. Their entire premise is the swarm principle.

Many will die, but some will survive.

Each and every time one of the many die, the customer leaves. Some sites have tried to "fix" this problem by sending you emails every few hours for days about the things "you forgot in your cart." This isn't a fix. This is an alcoholic refusing to admit they have more than a drinking problem.

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

#107

Post by seasoned_geek »

segmondy wrote: post #63
malux85 wrote: post #33

Earlier quoted context omitted.

Here's a couple of examples for you: I Sysadmined a VMS box running on a couple of AlphaServers (2100 and 2100A) if I recall. At one point a disgruntled employee had taken a 22 rifle into the server room and shot several rounds at the equipment, only 1 bullet hit, but it went through a RAM bank, the system disabled the faulty hardware and continued running. The other cool part was the interchangeable boards - the sys…

Ever work with Sun servers? Yeah, you could swap out cards, CPU, ram, drive, power, without halting or rebooting the OS. But not just Sun servers. This is not a feature unique to Alphaservers/VMS.

It was originally a DEC specific design copied/stolen by others. DEC created the design concept of a common back plane. Other than some logic switches to control power/enabling, there was nothing it provided. Every machine was completely customizable.

I'm not a hardware buy, but I believe this is a carry over from the VAX days long before there was SUN.

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

#108

Post by pedasmith »

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

For example: you could make a cluster-wide lock that you code uses to coordinate access to cluster-wide shared resource.

Locks on most OSes have an "outer scope" of a process or the machine.

Post reply on HN