[skissane]

I find them really interesting because they are a whole other world, the "road not taken". They are very different from Unix/POSIX/Linux/*BSD/macOS/etc, even moreso than Windows is. Windows is not a Unix, but it has borrowed a lot of ideas from Unix–and is arguably growing more Unix-like as time goes by, borrowing more and more ideas from Unix-land–Windows is a lot closer to Unix than most mainframe operating systems are–even MS-DOS is a lot closer to Unix than most mainframe operating systems (indeed, if you read the source code and design docs for MS-DOS 2, they repeatedly mention the influence upon it of Microsoft's Unix, Xenix.)

Consider some ideas which exist in z/OS but not in Unix or Windows:

- record-oriented file system: the filesystem is aware of the record-boundaries of files, whether they contain fixed length or variable length records, etc – and enforces them

- indexed files: key-value type files are built in to the filesystem, not some add-on library

- the catalog: a database mapping file paths (dataset names) to the volumes they are stored on: so you can move a file to another disk volume (or even to tape) without changing its filesystem path. You can kind of approximate this using mount points, symbolic links, etc – but it is a lot messier

- partitioned data sets (PDS/PDSE): like ZIP/TAR files, but again, built-in to the filesystem

- block-oriented terminals: you send/receive data to terminals as a screenful at a time, not a character at a time

- DDnames: your program inherits (the moral equivalent of) file descriptors, but instead of just having numbers, they have names (instead of fd 0, you have a DD called "SYSIN")

You can argue about whether the above features are sensible – the designers of Unix were well-aware of them, but decided they were examples of unnecessary complexity – but sensible or not, they are interesting.

[ASalazarMX]

> I find them really interesting because they are a whole other world, the "road not taken".

This is so interesting, having witnessed the commoditization of PCs, the Cloud, and now virtual desktops on the cloud. We're basically reinventing the multiuser mainframe after discovering it actually had good proposals.

The problem is, it's being reinvented with a monstrous degree of complexity and fragility. It's retaking the road not taken, but carrying the other road with as well.

[pjmlp]

And language environments, which keep oldie programms running on modern hardware without recompilation.

Something that neither UNIX nor Windows have fully embraced to the extent of mainframes/micros.

All the deployments from Java and .NET workloads end up with some kind of compromise to classical UNIX/Windows development.

[skissane]

> And language environments, which keep oldie programms running on modern hardware without recompilation.

I think we've had this discussion before. The Language Environment (LE) on z/OS doesn't do that. The Integrated Language Environment (ILE) on OS/400 [0] does do that. But while one part of ILE (the CEE runtime and its API) is common code between z/OS and OS/400 (and also VM, VSE, TPF and OS/2) – that bit doesn't do any of the "keep oldie programs running by recompilation" stuff. Whereas, the parts of ILE which does do that (the OMI to NMI translator, and the NMI to POWER translator), is 100% OS/400 specific, and has no equivalent on any other IBM platform (z/OS included). You seem to be getting led astray by the fact that "Language Environment" means a lot more in OS/400 than it does in MVS – it is a mistake to assume that just because the later uses the same phrase, that it uses it to mean anywhere near the same thing. LE on MVS is just one (relatively small) part of the capabilities provided by ILE on OS/400.

(Also, this "platform independence" doesn't really have anything to do with anything "Language Environment", since it pre-exists ILE entirely – EPM and OPM before it had the same ability. You are associating "Language Environment" with something which was never actually the selling point of ILE, since it was something OPM and EPM already could do, at least in principle. The real selling point of ILE is that it could support recursive/stack-based HLLs such as C and Pascal more efficiently than EPM, and support mixing code from multiple languages much more easily than OPM and EPM allowed. Plus, a lot of its implementation was shared with z/OS and AIX, which was a bonus for IBM – not just the CEE runtime, but also the compiler backend–the later is not considered part of LE on z/OS, rather part of the compiler products)

[0] Yes, IBM i, I know – but I hate that name, it is confusing. IBM should have just stuck with OS/400, it was far more memorable and distinctive.