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
... sorry, wrong list ...
Original-Nachricht
Betreff:Fwd: Re: 2GiB = address 4GiB
Datum: Wed, 05 Nov 2014 09:32:47 +0100
Von:Bernd Oppolzer bernd.oppol...@t-online.de
An: IBM Mainframe Discussion List ibm-m...@listserv.ua.edu
... should be storage access
USING ought to be as helpful as possible.
HLASM - like other products can be driven by user requests. The more
requests/votes we have - the higher up the list the requirement goes.
If the community feels this change is important/useful/desirable
then please raise a requirement and vote for it.
And z/VSE followed the same pattern as z/OS.
And, as a little extra, this is why the 31/64 line is called a BAR, not
a LINE. The unusable addresses are what is in the BAR. So, you can be
above the bar, or below the bar, but not in the bar. (No drinking
allowed. :-) )
Tony Thigpen
Bernd
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
It's important to note that the reservation of x'8000' through
x'' is merely to help avoid addressing issues, as well-explained
previously. It's not a fundamental issue at all, and the architecture
itself doesn't have any such restriction.
Also, you CAN allocate memory in this area
On Wed, Nov 5, 2014 at 8:57 AM, Steve Smith sasd...@gmail.com wrote:
It's important to note that the reservation of x'8000' through
x'' is merely to help avoid addressing issues, as well-explained
previously. It's not a fundamental issue at all, and the architecture
itself
Am 05.11.2014 15:18, schrieb Paul Gilmartin:
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
On 2014-11-05, at 05:10, Tony Thigpen wrote:
And z/VSE followed the same pattern as z/OS.
And, as a little extra, this is why the 31/64 line is called a BAR, not a
LINE. The unusable addresses are what is in the BAR. So, you can be above the
bar, or below the bar, but not in the bar. (No
On Wed, Nov 5, 2014 at 1:03 PM, Paul Gilmartin
0014e0e4a59b-dmarc-requ...@listserv.uga.edu wrote:
On 2014-11-05, at 05:10, Tony Thigpen wrote:
And z/VSE followed the same pattern as z/OS.
And, as a little extra, this is why the 31/64 line is called a BAR, not
a LINE. The unusable
On Wed, 5 Nov 2014 12:03:51 -0700, Paul Gilmartin paulgboul...@aim.com wrote:
Nevertheless, as long as z/OS and z/VSE exclude 2GiB = address 4GiB,
I prefer your interpretation. Is bar prevalent in VM or Linux argot?
But z/OS does not exclude that range anymore, gil, as others have said. It is
Yes, z/VM has a bar. With our first 64-bit version, there were some
restrictions that virtual machine pages for guest I/O had to be under the
bar. That was rather unpleasant for Linux that does not use dedicated
memory areas as I/O buffer. It got crowded under the bar.
And the 32-bit Linux s390
On 5 November 2014 16:32, John McKown john.archie.mck...@gmail.com wrote:
On Wed, Nov 5, 2014 at 8:57 AM, Steve Smith sasd...@gmail.com wrote:
It's important to note that the reservation of x'8000' through
x'' is merely to help avoid addressing issues, as well-explained
On 2014-11-05, at 13:11, Walt Farrell wrote:
On Wed, 5 Nov 2014 12:03:51 -0700, Paul Gilmartin paulgboul...@aim.com
wrote:
Nevertheless, as long as z/OS and z/VSE exclude 2GiB = address 4GiB,
I prefer your interpretation. Is bar prevalent in VM or Linux argot?
But z/OS does not
I stand corrected: at least with JVM7 the compressed references is by
having part of the heap under the 4G used for a certain subset of objects
that is most often pointed at. As with any partitioning, this creates
opportunities for running out of memory though there is enough space on the
heap.
On 5 November 2014 16:19, Paul Gilmartin
0014e0e4a59b-dmarc-requ...@listserv.uga.edu wrote:
The bar is infinitely thin,
I'll trust you; the manual appears not to affirm what others say.
Architecturally (at both the P of O and z/OS levels) the bar may well
be infinitely thin, but that
On 2014-11-05, at 08:54, Bernd Oppolzer wrote:
load a 31 bit address which points to storage below the bar from a fullword;
the fullword has the first bit set (maybe because it is the last fullword in
an address list).
The target of the load is a 64 bit register (say reg 5), where the left
On Wed, 5 Nov 2014 18:07:17 -0500, Tony Harminc t...@harminc.com wrote:
Architecturally (at both the P of O and z/OS levels) the bar may well
be infinitely thin, but that doesn't mean that IARV64 and friends will
hand you an address between 2GiB and 4GiB.
As others have mentioned, IARV64 _will_
On Wed, 5 Nov 2014 14:19:59 -0700, Paul Gilmartin paulgboul...@aim.com wrote:
I don't recall that anyone has said z/OS does not exclude that range anymore.
In fact most of the plies in this thread seem to say that range is excluded
and it's a good thing.
Someone earlier in this thread
I can't remember where this is fully documented, but 64-bit storage is
currently divided into about five types: Restricted (2G-32G), LSA, Low
(sic) User Region, Common, and Shared. On my test system, LSA starts at
x'8_', User region at x'48_', Common at x'1EF_8000',
and
20 matches
Mail list logo
