On Wed, 7 Aug 2013 12:04:51 -0400, Charles Mills wrote: > >Parenthetically, no need for a 24-bit API because the whole point would be to >allow QSAM to exploit 32-bit. > Underreacher. While 32-bit may be twice as good as 31-bit, it's not nearly as good as 64-bit. Anyone who designs a new control block with less than 64-bit pointers, even for entry point addresses, is shortsighted. It'll (maybe?) happen someday. Until then, David's "factory function" can stuff the 64-bit pointers with addresses below-the-bar. Or am I underreaching? If the structure is truly opaque, the programmer shouldn't care (or even know) what size pointers it contains. But the API should be strictly 64-bit (until 128 looms on the horizon -- I understand ZFS is already 128-bit). And even then, the distinction should affect only Assembler programs; HLL programs should just be recompiled with the revised header files.
I don't know how strongly Java is committed to 32 GiB address spaces with 32-bit pointers. Flight of fancy: If z/OS were truly well-parameterized, a designer could simply change _one_ "whatever EQU 44" to "whatever EQU 100" in a mapping macro and recompile the entire OS to get 100-character DSN capability. (We tried something like that with one of our products a couple decades ago. Sure enough, the hardware designers thought of a way to add an enhancement we hadn't parameterized -- something like adding a new dimension to the topology.) -- gil ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
