On 2014-11-05, at 01:27, Bernd Oppolzer wrote: > Maybe it can be explained this way: > > when we migrated from 24 bit to 31 bit, we had lots of problems > when loading 24 bit addresses (for example parameter addresses) > from fullwords and using them in 31 bit mode, > and the addresses had some non zero values in the first (leftmost) byte > of the register (which was no problem in 24 bit mode). There was no way > around this but to clean the register's first byte before doing the storage > address (if the address was a 24 bit address in the beginning). > > Now we have the same situation; the leftmost bit of the fullword is > ignored when using the addresses in storage access (in 31 bit mode), > be it 0 or 1 ... and it is 1 sometimes. > > When expanding a 31 bit address to 64 bit, simply by adding 32 zero > bits on the left or by loading a fullword into the right half of a 64 bit > register, > the 31 bit address will be the wrong address, if the leftmost bit in the > fullword > was set. > A similar approach as for 24 to 31 bit conversion applies. Simply clear bit 0.
> But this time we have the chance to flag such errors, simply by excluding this > address range (0x00000000_80000000 to 0x00000000_FFFFFFFF) from > the range of allowable 64 bit addresses in z/OS. It is, given the overall > address range, not too large. > Are you suggesting that someone might do 64-bit STORAGE OBTAIN and save only low-order fullword. This will certainly cause problems, but those are not solved by excluding that address range. Or that someone do 64-bit STORAGE OBTAIN and decide based on whether the high-order fullword is 0 that it suffices only to store the right half? I still don't envision a plausible scenario in which a problem is avoided by excluding that range of addresses. Supply context. More: I understand that BASSM sets bit 63 of the return address to indicate that the return address is to AMODE 64. Does Content Supervision follow the same convention, setting bit 63 when LOADing an AMODE 64 module? Hmmm. I believe I can declare an ENTRY at an odd offset from the CSECT. (It had better be data, not a branch target.) I can make that ENTRY an ALIAS for my module. When I LOAD it, how can I tell if it the address returned with bit 63 set indicates an AMODE 64 CSECT or an actual odd address. Perhaps the answer is, "Don't do that!" Does Binder resolve 31-bit V-CONs setting bit 0 to indicate AMODE 31? Does Binder resolve 64-bit V-CONs setting bit 63 to indicate AMODE 64? -- gil
