Earlier quoted context omitted.
Could you give an example of such an industry? VMS to me has always been that OS that everyone claimed to be better than UNIX-likes, but none could explain why.
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…
OpenVMS State of the Port to x86_64 [pdf]
71–80 of 108 posts
Re: OpenVMS State of the Port to x86_64 [pdf]
#72Earlier quoted context omitted.
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]
#73Earlier quoted context omitted.
See also Tandem, another HP owned system now. https://en.wikipedia.org/wiki/NonStop_(server_computers)
Which makes me wonder - does anyone know if HP has plans to port NonStop to some non-Itanium platform? I have never worked with this system, but I have heard great things about its scalability and availability.
Re: OpenVMS State of the Port to x86_64 [pdf]
#74Earlier quoted context omitted.
"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…
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 comparing hardware about 3-4 generations apart and blaming the software for the issues.. if you were comparing with 500MHz Alphas, etc, then you might have a point..
Re: OpenVMS State of the Port to x86_64 [pdf]
#75It was ported to Itanium while the x84 port and the POSIX compatibility project was never completed.
Re: OpenVMS State of the Port to x86_64 [pdf]
#76Earlier quoted context omitted.
Which makes me wonder - does anyone know if HP has plans to port NonStop to some non-Itanium platform? I have never worked with this system, but I have heard great things about its scalability and availability.
Nonstop has already been ported to x86-64 some years ago. It runs fine there - with better performance than it did on Itanium.
Re: OpenVMS State of the Port to x86_64 [pdf]
#77Earlier 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.
You have a full parts/warehouse inventory system and invoicing internally and to other mechanics. A service system (including rosters and timesheets) and it's own invoicing system to customers. You need a vehicle module to manage all the local laws and taxes as well as interfacing with manufacturer systems for models and options (which are God awful undocumented weird binary formats over long dead networks - sometimes hardwired through parts of the phone companies that even they don't know they have anymore) so you can sell to customers.
So that's 3 different invoicing systems to start. It all needs to be underpinned with an extremely flexible accounting system in the back end because every dealer does stuff differently but all of those things are related. The parts department sells to the service department at a discount; the service department prepares new vehicles for sale (called pre-delivery) and bonuses and rebates occur through each step.
You need to import a lot more data covering log book service information and parts catalogs. And lots of reports for those car companies and online sellers and more.
Some of that isn't exactly a programmers problem but the breadth of the issue and lack of generalised knowledge sources (and how every car manufacturer does things completely differently), it's a minefield to keep one going let alone building a new one.
Consequently most of the world runs on only 2 or 3 systems and they're all ancient and generally the companies that develop them are awful and treat customers like garbage. There's a lot of vendor lock in and manufacturers fighting each other.
Car dealerships have a tough job. Also their accountants are near God level skills wise.
Anyway I don't think I answered your question. Yes I also don't know exactly what happened but yeah it was a disaster that only happened to work out because of millions of dollars. Once it WAS ready though money started flowing in because dealers are desperate to get away from the existing awful vendors. On the other hand each wanted so much custom functionality that it led to work pipelines planned years in advance by the time I left - and that doesn't make for happy customers either.
Re: OpenVMS State of the Port to x86_64 [pdf]
#78Without giving away any specific customers, I have personally dealt with VMS customers in the following markets: nuclear industry (power plants, research reactors, reprocessing plants, research labs), military (weapons systems, logistics), law enforcement, railroads, airports, healthcare, manufacturing (process control, logistics), retail, and I may have overlooked some markets.
Re: OpenVMS State of the Port to x86_64 [pdf]
#79Re: OpenVMS State of the Port to x86_64 [pdf]
#80Earlier 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…
TCP connections are never dropped ETC One thing I wonder now: how can this work? Is there a physical load balancer in front or something?