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.

Microfocus COBOL also matters - there's non-trivial amount of code that is still being worked on, in COBOL, that runs these days mainly on RHEL machines and is compiled with Microfocus.

As for handling destructuring files, how useful it is really shows when you consider how easier many tasks become when you have access to such facility - even if nowadays you might expect it to be handled by extra compilation step that uses protocol buffers or something similar.

Modern programming languages are more than capable of providing an abstraction layer that can offer seamless file->struct and struct->file conversions.

It's basically the equivalent of ORM for relational database.

But nobody does it not because it's hard or because the language doesn't support it. They don't do it because we no longer think of file system the main "database" that stores your application state.

Instead we think of the filesystem as a lower level building block for higher level abstractions (such as relational or whatnot databases)

At least in south America, I saw in almost every financial institution, a lot of cobol being used until today.

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

https://bluemedora.com/the-hard-and-the-soft-of-oracle-licen...

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.

Yes, and the z/OS USS is what I call aggressively POSIX-compliant. Its mission in life is to hurt you with strict adherence to the spec, not ever help you!

If there's any optional part of POSIX, it's not in there. You only get the 'MUST' parts of the base spec. No optional extensions, etc. When you're porting over C code to z/OS USS, you are often surprised when things you assumed were just part of every POSIX implementation aren't there. Fun times for all!

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.

Yah, given my experience, you buy the mainframe for one of the native zos/etc flavors, and then the IBM sales people basically throw in the IFL's which will never get used for the zos/etc workloads effectively for such a nominal price, they might as well be free.

Then you have half a mainframe of capacity lying about, and why not run some linux workloads on it.

I find it _really_ hard to believe that outside of a few really narrow niches anyone is really buying mainframes to run linux workloads. Its just not cost effective.

PS: and then of course IBM gets to add it to their total "sold capacity" for the quarter to make it look like the business is growing. So they _want_ you to use all that idle hardware.

Or case 3: You still have ancient RPG code running that makes the business go $.

> So either these are industries that are exceptionally difficult to break into

AIUI, Oxide Computer is targeting the "private cloud" space which is sort of adjacent to this stuff and could easily intrude on it. Of course they're based on AMD EPYC hardware, but the rest of the system is custom designed for ease of management and reliability.