back
37 comments
Very cool. Good to see OpenVMS is still alive and kicking that also on AlphaServer. It is the best command line operating system I ever used. Never liked unix variants after that. Commands are so intuitive copy is copy not cp. File versioning is the best. I never had to worry about saving versions of my Fortran code files.
I formed the opposite opinion. To form a pipeline on unix this is more natural to me:

cat somefile | somecommand

But in DCL on VMS:

PIPE cat somefile | somecommand

That's small beer compared to the way file paths are specified. It's been too long since i last used a VMS cluster so i can't remember the syntax off hand, but it's pretty clunky.

Hacker news is very unix focused. This is convenient, but I'd love to see some more blog posts about what's made platforms like VMS or mainframe platforms awesome to work with. (where do these crowds hang out?)
HP OpenVMS site http://h71000.www7.hp.com maybe the starting point to further explore it. Also, they have a hobbyist license available for free. I haven't been involved with VMS since 2000 so not sure where such people hang out.

I started my career as Fortran developer on OpenVMS for process control systems and process simulations in early 90s. OpenVMS was the choice platform for most mission critical/ life critical operations and for manufacturing process simulations then.

We ran a few pair of OpenVMS nodes in cluster to operate multimillion dollar petrochemical production facility. The share-everything clustering was cool. I don't think I have seen that since.

Actually OpenVMS helped me make transition from petrochemical to technology in 2000. A tech company was trying to find someone with prior experience in OpenVMS to support customers using their optical storage library management software on OpenVMS/Alpha. That's when I transitioned from controls to data storage.

VMS was awesome to work with. Highly interactive and intuitive. I still prefer *nix, but my time on VMS was reasonably pleasant.

Mainframe, not so much - imagine programming in a webform's text box where the endpoint might have gone away by the time you submit.

And it looks like as if OpenVMS escaped the deathbed once again: http://www.computerworld.com/s/article/9250087/HP_gives_Open...
A question for the more knowledgeable: I remember reading that OpenVMS was not ported to i386 (and later) because the CPU didn't have sufficient support. Can somebody elaborate on what exactly CPU features OpenVMS needs?
That was an excuse. The real reason was that management of the succession of companies that owned VMS saw it as a cash cow to be milked at the high profit margins associated with proprietary minicomputer systems, not as a mass-market product.
It is sometimes claimed that x86 cannot support VMS because VMS makes use of four CPU protection rings, despite the fact that x86 has four protection rings...
4 protection rings of x86 are mostly not usable for anything, as they apply to descriptors, not memory page (there is only single user/supervisor bit in page table entry). The whole 286 descriptor based memory protection model is mostly unusable for C-and-separate-processes multitasking model (and has relatively significant overhead).
If you've not listened to it, this podcast is probably going to be of interest to you - http://www.imore.com/debug-29-jeff-mcleman-porting-kernels

(An interview with Jeff McLeman who worked at DEC, he discusses VMS/Alpha/NT kernel work)

They are porting it now: http://www.marketwatch.com/story/vms-software-inc-named-excl...
> The cluster supports many programming languages, including: BASIC, C/C++, Fortran, Cobol, Ada (on Alpha), Bliss, Macro32, DCL scripting, Java, and Pascal.

That's probably historical, but I wonder what's the point to advertise that the cluster supports Cobol for example?

Because COBOL is alive and well. It's not interesting, but it's far from dead.

A friend of mine works on a COBOL system that's responsible for calculating pension payments for former government employees. COBOL is good enough for this application, since it's basically just a glorified pile of if-statements.

Rewriting everything in the hot-new-language-of-the-year would almost certainly introduce bugs, so instead of screwing up people's pension checks every couple of years, they just pay a my friend to know COBOL and to keep the rules up to date.

There's still enough of a community behind COBOL that there's really no reason not to do this. COBOL compilers continue to be maintained, and even the language itself is getting updated (see e.g. https://en.wikipedia.org/wiki/COBOL#COBOL_2014).

> Rewriting everything in the hot-new-language-of-the-year would almost certainly introduce bugs

Yes, that's the point I usually hear. I.e. that it's used for legacy applications, just because switching to anything else doesn't worth the effort. I'd be more surprised however when it would be used for any new project.

I guarantee something you do today will require some COBOL to be run on your behalf.
That's very possible, but I doubt anyone would make something new using it. As far as I know, it's used only in cases when switching is too difficult.
I'm aware of several prominent companies in the Pittsburgh region that were on centralized mainframes and now use Micro Focus or some other "modern" COBOL for their core systems. These aren't legacy but are actively developed and extended. To look at the screens, etc., you'd likely never guess that the underlying code is COBOL. If it does the job and serves the business well, why switch?
> If it does the job and serves the business well, why switch?

That's of course understandable (for keeping legacy systems), but new systems deployed with using Cobol is not so expected.

We established that your limited experience in the business hasn't exposed you to a lot of what is going on outside of what is reported in HN. Why do you insist in on flaunting that fact?
The reasons for using COBOL in any new project weren't explained, so whatever was "established" is irrelevant to the discussion.
I was at a Very Large insurance company last month where they discussed a suite of new Cobol applications they were deploying and what infrastructure they were going to need to deploy them (very large $$$ worth, btw). They could have done it in Java (and do many things in it), but believed that because of their experience and the critical nature of the apps, Cobol was much less risky. As a tangent, they tried at one point to change their development language to Smalltalk (because at the time it was what the cool kids wanted to use), but we don't mention that in their presence.

Once your experience in development evolves beyond buzzword-bingo web apps and obsession with faddish language features, you find all sorts of real work being done in uncool things like Cobol, Ada, Fortran, VB, etc.

Some people might be looking for a machine to play around with Cobol?
That's what I wonder about. Most people who "play around" with it usually strongly want to get rid of it and continue using it because they can't switch for some reason.
Citation needed.
If your project supports x why wouldn't you tell people?
wow, i worked on openvms for my first job out of school, amazing operating system, but i didnt get too much into the kernel, was wrapping cobol apps with ejb's. a pretty amazing os, you could cluster something like 256 some nodes and the os would distribute jobs across nodes depending on how you set up a cluster. i just remember everyone would say the os would have uptime in terms of years, not hours!

i used to also dabble a bit in dcl, digital command line, which is more like the shell scripting language for openvms.

So what are the features that OpenVMS has that others do not have? (Just curious)
Like most things you have to bear in mind the time context - VAX/VMS had robust clustering of a solid multi-user, OS pre-1990. That was before Linux, the first release of SunOS and before Windows had networking.
The versioning filesystem is very nice - better than snapshotting, it's as though the whole system were under version control, and it's integrated with the whole OS.

Performance and security were reputedly very good, though I've no idea how it's kept up these days.

I've never used it but I read a lot of accounts of superb clustering capabilities. You can have clusters spanning several OS releases on different hardware platforms.
Clustering on VMS is mostly about marketing and integration, VMS cluster is essentially only about shared filesystem and same effect can be had by means of NFS and some kind of centralized management on Unix (even across different Unix OSes). It does not do any magic like process migration and intra-cluster shared memory.

From technical standpoint interesting feature is sane approach to asynchronous IO and IPC (think libevent in kernel).

There is nothing "only" about a clustered shared filesystem.

There may be a hundred of them but none works off the shelf for all applications. There are a lot of details in there.

You could probably make the point that early Google was "only" a clustered filesystem plus some apps running on top on it.

I can’t find the original source but I remember reading an article about a VMS cluster that was moved piecemeal between two towns in Belgium without any downtime. Individual machines went down during the move obviously, but the cluster as a whole was able to stay up.
I remember this - I thought it was on el reg, but worse, it was theinq :)

https://web.archive.org/web/20031219162954/http://www.theinq...

Wow, so it was. Takes me back :) Thanks for digging it up! Here’s the source story: http://www.openvms.org/stories.php?story=03/11/28/7758863
I love the names of the nodes on Death Row:

JACK [The Ripper] [Ed] GEIN