IBM Mainframe Forum

You will sometimes see register contents displayed as -

arararar/hhhhhhhh or
arararar/hhhhhhhh_hhhhhhhh or
hhhhhhhh_hhhhhhhh

Arararar is the "access register" contents. When your program is in "access register" mode, a non-zero "access register" value permits your program to use the contents of a "data space" or "hiper space." Each general purpose register has a corresponding "access register" it can use. Programs that do not use "access register" addressing have been known to use the "access registers" as a sort of save area, but this isn't necessarily safe, as an "access register" value of 0 uses the "home" address space rather than a "data space" or "hiper space" when it is in "access register" mode. Very few user programs use data spaces or hiper spaces, or use access registers improperly.

A register displayed as hhhhhhhh_hhhhhhhh is showing all 64 bits of the register. The traditional 32-bit register instructions just use bits 32 to 63 of the register.

Do you think that the concepts of data- and hiperspaces become less important with the arising of 64bit addressing? With 64bit addressing each address space can store up to 16exabyte, in contrast to 2gigabyte with 32bit addresses.

I guess there will remain some important features of dataspaces (separate the data of different tasks in the same address space from each other), but in general, the benefits of data- and hiperspaces fade away.

This is only my opinion.

LotharLochkarte wrote:Do you think that the concepts of data- and hiperspaces become less important with the arising of 64bit addressing? With 64bit addressing each address space can store up to 16exabyte, in contrast to 2gigabyte with 32bit addresses.

I guess there will remain some important features of dataspaces (separate the data of different tasks in the same address space from each other), but in general, the benefits of data- and hiperspaces fade away.

This is only my opinion.

I generally agree. However, the ability to link a data space to a VSAM Linear data set (at least up to 2 gig) offers some intriguing possibilities that are not generally exploited.

I thought of trying to exploit the idea in your second paragraph into one of my programs, but I never got around to it. The requirement to move a fairly substantial amount of data from storage to the data space, since I don't think I could perform regular I/O directly into the data space, would probably have put too large a performance penalty in the program to make the potential advantages of the idea useful. In addition, the program would create hundreds, or possibly thousands, of concurrent data spaces, and I was never certain the system wouldn't have choked on that.

You are right, using data-In-virtual to map a VSM linear dataset to virtual storage sounds interesting.

However, do you know why data- and hiperspaces are still limited to 2GB? I am wondering, why we can't (at least in the case of dataspaces) exploit 64bit addresses here too.

LotharLochkarte wrote:... However, do you know why data- and hiperspaces are still limited to 2GB? I am wondering, why we can't (at least in the case of dataspaces) exploit 64bit addresses here too.

I can only guess, but as has been mentioned, linking data spaces to a VSAM linear data set seems to run into VSAM RBA limits. Given the limited use of this facility, I am guessing IBM just did not want to expand it.

Good point, this could be an obstacle.