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.
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.
Mainframe, not so much - imagine programming in a webform's text box where the endpoint might have gone away by the time you submit.
(An interview with Jeff McLeman who worked at DEC, he discusses VMS/Alpha/NT kernel work)
That's probably historical, but I wonder what's the point to advertise that the cluster supports Cobol for example?
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).
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.
That's of course understandable (for keeping legacy systems), but new systems deployed with using Cobol is not so expected.
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.
i used to also dabble a bit in dcl, digital command line, which is more like the shell scripting language for openvms.
Performance and security were reputedly very good, though I've no idea how it's kept up these days.
From technical standpoint interesting feature is sane approach to asynchronous IO and IPC (think libevent in kernel).
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.
JACK [The Ripper]