News for hackers. Stuff that matters.
Re:IBM to cut about 3,900 workers while still hiring in ‘hig... by pjmlp on Friday January 27, 2023 @01:39AM (#34543295)
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.

Re:IBM to cut about 3,900 workers while still hiring in ‘hig... by skissane on Friday January 27, 2023 @05:26AM (#34544542)
> 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.

Re:IBM to cut about 3,900 workers while still hiring in ‘hig... by jimbo9991 on Friday January 27, 2023 @08:20PM (#34554091)
To expand on what you said for those curious about what Language Environment actually is on z/OS:

Language Environment on z/OS is basically a shared standard library and runtime used (sometimes optional) by most of the different high level languages.

It defines it's own register usage conventions and calling convention, and so you must be aware when writing and/or compiling programs whether you want it to be LE compliant or not. The calling convention in LE is very different from the convention used by OS level programs (typically written in Assembler or C).

Most of the time if you are writing a (compiled) application program for z/OS it's best to make it LE compliant. However the incompatibility with base z/OS calling conventions is frustrating because systems programmers mostly avoid writing LE compliant programs due to it being heavy and not working in some of the environments closer to the metal.

So while LE on z/OS is pretty extensive and gives you a common API to program against in different languages, it's also caused a bit of an ABI split and made it harder to share tools between systems and application programmers, which is unfortunate.

Like the above post said, it doesn't really have much to do with the z/OS compatibility story. If anything, the older the program the more likely it is to not work under LE due to LE breaking compatibility with the original calling convention.

z/OS compatibility is kind of oversold to be perfectly honest. Yes, it is likely you can continue to run your very old programs due to 24 and 31bit addressing still being an option, but you better be pretty damn careful to backup that executable if your thinking of ever trying to recompile.