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