The term "32-bit program" has been repeated in this thread. It appears that the OP means by this that the program can be AMODE 31 or AMODE 64 but never directly touches bits 0-31 of a GR.
It appears that the OP is interested in expanding the program to accommodate twice as much storage as it has access today (which in general is a very limited increase and one might call it short-sighted since how often is "twice as much" enough, except as a temporary measure?), while still having to deal with being in AMODE 64 when using the storage that happens to be within the bar, but not wanting to use 8-byte data pointers and not wanting to use the available instructions that set 8-byte registers. The OP wrote: >Any 32-bit program currently coming up against the 2 GiB barrier can have >its life extended by bumping the limit up to 4 GiB. "Extending life" is not going to be thought to be sufficient rationale for what would be a very large effort. Since the program would already need to be changed, having it deal fully with 64-bit addresses is often not a big deal. Anyone is welcome to submit an RFE for just about anything that they want. An RFE requesting this function will almost certainly be declined. I say that only to set realistic expectations. Perhaps some are not aware that the area 2G-32G is already defined for use by Java and other language runtimes, in very specific implementations. Peter Relson z/OS Core Technology Design ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
