IBM tunes up Java for z196 mainframes Software almost always lags behind the hardware it runs on. This week, IBM tuned up its Java virtual machines and software development kits for its System z mainframe line to take advantage of new instructions in the new zEnterprise 196 mainframes. The zEnterprise 196 mainframes were announced last July and began shipping in …
For backward compatibility with existing 24 bit applications!
The end of a list of parameter pointers is marked by setting the high-order bit in the last address. If they went to 32-bits, all 24 bit application would break since you could not determine whether an address with the high-order bit marked the end of the parameter list or was a value larger than 2GB.
Going with 31-bits only meant executables built in the 60's and 70's can (potentially) still run under current versions of the hardware and the OS.
Most if not all of the 24 bit programs can still be runing on Z/os. Frankly we have an application(s) that was last compiled in 1968 and still runs unchanged in Z/os.
OF course all 31 bit programs can do so.
There are some minor exceptions to the rule, but if we can keep it at application code level then we can run all programs on Z/os.
The s/360 line of mainframes originally used 24-bit addressing and had the spare 8 bits to save various things depending on the instruction executed. Back in the mid-60's, 16Mb of main storage would have been quite extraordinary, not to mention extremely expensive (IIRC IBM used to "rent" main storage at about $100 per K per month); this memory would be ferrite code, BTW.
When it became desirable somewhat later on to remove this constraint, in order to maintain backwards compatability - a major feature of the s/3xx/z line over the years; you can take a program compiled in the 60's and run it on your z/196 today - the hi-order bit of an address was used to flag the addressing mode leaving 31 bits for the actual address.
A modern IBM mainframe can happily run 24, 31 and 64 bit addressing modes as required.
Just remember back to when memory was expensize 10K (or more) per megabyte.
To save memory IBM used 24 bit addressing. Come the 70's 24 bit wasn't enough and IBM went 31 bit.
The final push to 64 bit really hasn't happened yet (dispite what IBM says). its real tricky to get in and out of 64 bit execution. Dispite IBM's hullabaloo there are still areas( large) that just do not allow 64 bit addressing to work. One of my favorites (and talk about not getting it right) is IBM's ICF catalog
IBM did not allow for vast (by then standards) of large disks and size of files.
AFAIK IBM's DB2 is being held back because of ICF catalog (and other constraints). This needs to many parts of the OS to be changed to be able to be done easily. Especially with a floating code base (some guess some knowledge for the last statement).
It can be done but it will not be easy as essentially IBM has to rewite a access method. Rewrite is probably a bad term but they have to go over millions of lines of code to find problems before rewrite.
COBOL can't get their act together with 64 bits LONG LONG STORY so do not think that VSAM will be easy.
"The final push to 64 bit really hasn't happened yet (dispite what IBM says). its real tricky to get in and out of 64 bit execution. Dispite IBM's hullabaloo there are still areas( large) that just do not allow 64 bit addressing to work. One of my favorites (and talk about not getting it right) is IBM's ICF catalog"
You must be using the wrong operating system and applications ;) Just kidding.
It's really easy to make 31-bit or 64-bit applications on Linux. It's just a gcc flag. The current version of RHEL and SLES are 64-bit only kernels with compatibility libraries for 31-bit apps.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
