Less dead than perl by far. I've seen a lot of new COBOL going into production just this year. New versions of the compiler (the IBM one, the only one that really matters for COBOL) are still being released. A while back they went to the trouble of implementing full JSON serialization/deserialization. You would be surprised how many web services are pretty much just COBOL the minute the server needs to do anything with files or databases or whatnot.
As somebody that grew up on C and mostly doesn't work on the applications programming side of things, it was always tough to get my head around why so many people still wanted to write COBOL. Over the years though I've concluded that its simply a better language for certain kinds of tasks than anything created since. And there has been no shortage of support in keeping it relevant and easy to integrate with modern systems.
It would be interesting to see the COBOL record IO and destructuring of files and whatnot be implemented in a more modern language. I don't think anybody particularly cares for COBOL syntax, but the programming paradigm it supports doesn't have any other major players. Nobody has ever really even tried, probably because the types of people that usually create programming languages have no connections to the somewhat closed world of COBOL enthusiasts at large corporations. Certainly an interesting idea for a hobby project though, there are a lot of interesting places you could take a mixed COBOL/functional language type thing.
For instance, a function would take one file and output another, file structures and record structures could be interpreted as data types, archiving files would be treated as a side effect of the system essentially (or potentially if you get real crazy, make that some sort of functional abstraction as well). Just spitballing here because it's a fantastic idea that I would love to see. There is no reason that working with files has to necessarily be treated as entirely external to the program/a side effect, so long as you take care to have some sort of way to deal with acquiring locks/contention issues and whatnot. Not a problem on mainframes, but there would need to be some systems features implementing to make that sort of paradigm effective in a Unix style environment. I'm not sure it could be done entirely in a runtime, a lot of that state would really need to be global.
As somebody who likes it I think I would explain it along the lines of FreeBSD vs Linux.
AIX is a complete package OS with some nice enterprise features, and it is modern and similar enough to make porting from Linux not too terribly difficult. Even something like RHEL is still very much more in the Linux tradition of lots of pieces of independently developed software kinda thrown together and called an OS, at times haphazardly.
That being said, we of course run RHEL as well, but mostly for cost reasons for less important applications, as opposed to any particular dislike for AIX.
USS on zOS is a much more difficult IBM UNIX to work with in my opinion, and tends to generate stronger opinions from both sides of the proprietary/OSS fence. They are making progress, but the compiler and compatibility situation is not as good as POWER/AIX.
If POWER LPARs are the same as Z LPARs then a lot of it comes down to the difference in licensing between hard and soft partitioned VMs. On a typical VM Oracle will charge for the entire cost of the machine, even if the DB is only running on a VM with a fraction of the resources, due to it being considered a soft partition.
At least on Z series mainframes, LPARs are considered hard partitions (handled by PR/SM, not the OS like a KVM situation) and are actually treated as different machines.
I am not sure if this is the case with POWER.
I've never heard of this website and don't know if they are a decent resource, but they seem to cover the issue the way I remember it. Looks like they are offering a license management product that tries to warn Oracle customers about this consideration. I'm sure Oracle slaps people pretty hard over this during their first audits, maybe even hard enough to get a company to shell out for IBM hardware :).
This is a key part of IBMs strategy, since it seems that LPARs on mainframes are treated as hard partitions and do not incur the same "whole machine" cost as VMs. At least that is what IBM themselves say when asked what the target audience is for their Linux only mainframes, which seems to be over 50% just for Oracle.
I only have experience with Z and not as much with POWER systems, so I'm not sure if LPARs on POWER are similar technology or if they are just VMs. But if they are the same that would go a long way in explaining how companies plan to reduce cost by going with IBM despite the increased core multiple licensing cost.
I would recommend focusing on DB2 and Oracle rather than MSSQL if you are trying to learn about that. MSSQL is not particularly expensive in comparison and doesn't really try to compete in the big enterprise league. It's much more similar to FOSS solutions.
Which folks haven't mentioned yet, but z/OS is also a proprietary UNIX, albeit in a very strange way given that it is sorta like a subsystem/different way of looking at the same things, but is also in implemented in the base control program (kernel), so it isn't really a subsystem.
And it isn't the same as AIX. IBM has two alive commercial UNIXs, which is kinda wild.
I like it. The structure of the code you write looks much more similar to what you would write on a piece of paper than Haskell (for instance, getting rid of in, the pulling into scope at the top). Not to mention the primitive version of the language also resembles how you would write in math much better than lambda calculus (which I acknowledge probably was never a goal of lambda calculus).
This doesn't present any examples of something that would be useful in the real world. But come-on, this was presented at a Haskell conference it looks like.
For anybody with an interest in the "mathish" flavor of functional languages, this certainly has a lot of promise as a foundation to build on.
The thing is, there aren't really any successful greenfield developments in these types of business spaces. So either these are industries that are exceptionally difficult to break into (which I think is at least partially true), or the type of computing they do actually benefits from being done on a mainframe (which is also true given that there is a lot of record processing for these industries, and not too much serving lots of web requests to users).
Of course, all of these companies also have x86 servers that run the customer facing web apps and stuff. You really wouldn't want to waste your MSUs running web servers, although I'll admit I don't know if these new Linux mainframes are charged by rolling avg MSUs or other MSU metrics. Traditionally, Linux on Z has had more favorable pricing due to the ability to use IFLs and basically just declare that a cores MSU usage doesn't count towards your licensing since it's been locked to only running Linux.
As somebody that grew up on C and mostly doesn't work on the applications programming side of things, it was always tough to get my head around why so many people still wanted to write COBOL. Over the years though I've concluded that its simply a better language for certain kinds of tasks than anything created since. And there has been no shortage of support in keeping it relevant and easy to integrate with modern systems.
It would be interesting to see the COBOL record IO and destructuring of files and whatnot be implemented in a more modern language. I don't think anybody particularly cares for COBOL syntax, but the programming paradigm it supports doesn't have any other major players. Nobody has ever really even tried, probably because the types of people that usually create programming languages have no connections to the somewhat closed world of COBOL enthusiasts at large corporations. Certainly an interesting idea for a hobby project though, there are a lot of interesting places you could take a mixed COBOL/functional language type thing.
For instance, a function would take one file and output another, file structures and record structures could be interpreted as data types, archiving files would be treated as a side effect of the system essentially (or potentially if you get real crazy, make that some sort of functional abstraction as well). Just spitballing here because it's a fantastic idea that I would love to see. There is no reason that working with files has to necessarily be treated as entirely external to the program/a side effect, so long as you take care to have some sort of way to deal with acquiring locks/contention issues and whatnot. Not a problem on mainframes, but there would need to be some systems features implementing to make that sort of paradigm effective in a Unix style environment. I'm not sure it could be done entirely in a runtime, a lot of that state would really need to be global.