I still don't envision a plausible scenario in which a problem is avoided
by excluding that range of addresses. Supply context.
Many start a conversion to AMODE 64 by changing to AMODE 64 without
adequate analysis of their data. Maybe they even clear all the high
halves.
If there was L to
On Wed, 5 Nov 2014 14:19:59 -0700, Paul Gilmartin paulgboul...@aim.com wrote:
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
. Smith wrote:
On Wed, 5 Nov 2014 14:19:59 -0700, Paul Gilmartin paulgboul...@aim.com wrote:
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
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
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
as z/OS and z/VSE exclude 2GiB = address 4GiB,
I prefer your interpretation. Is bar prevalent in VM or Linux argot?
-- gil
immediately below 2GiB. Any address = 2GiB
is considered *above*, never in, the BAR.
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?
On the Linux-390 forum, I've never seen the use of bar
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
some IBM employees, perhaps unofficial, is that the BAR is an
infinitesimal boundary immediately below 2GiB. Any address = 2GiB
is considered *above*, never in, the BAR.
Nevertheless, as long as z/OS and z/VSE exclude 2GiB = address 4GiB,
I prefer your interpretation. Is bar prevalent
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
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
I know that z/OS STORAGE OBTAIN will never return a block of storage
with 2GiB = address 4GiB. But what's the rationale for this?
ISTR that I once knew, but I've forgotten, or always misunderstood.
Is there a superstitious phobia of having bit 32 of a 64-bit
address be 1? If so, isn't 6GiB
the range as unusable.
Tony Thigpen
Paul Gilmartin wrote on 11/04/2014 06:58 PM:
I know that z/OS STORAGE OBTAIN will never return a block of storage
with 2GiB = address 4GiB. But what's the rationale for this?
ISTR that I once knew, but I've forgotten, or always misunderstood.
Is there a superstitious
On 2014-11-04, at 17:07, Tony Thigpen wrote:
The first bit of the address in the PSW indicates that the address is a 31
bit address. So, there was ambiguity for any address with the first bit set
on.
Was the bit on because it was 31bit code setting the flag, or was it a real
address in
It's only the single bit that causes ambiguity:
8000 or 8
81234567 can be 01234567 (31bit mode)
81234567 can be 81234568 (64bit mode)
SO, they just said that any address with the following bit is invalid:
8000
Tony Thigpen
Paul Gilmartin wrote
A 64-bit address is only ambiguous when the high word is zero and the high bit
of the low word is on. When the high word is non-zero all 32 bits of the low
word can address storage locations without ambiguity.
Chuck Arney
Arney Computer System
On Nov 4, 2014, at 6:22 PM, Paul Gilmartin
Thanks Chuck. That was the piece I was forgetting to actually say.
Tony Thigpen
Chuck Arney wrote on 11/04/2014 09:25 PM:
A 64-bit address is only ambiguous when the high word is zero and the high bit
of the low word is on. When the high word is non-zero all 32 bits of the low
word can
On 2014-11-04, at 19:25, Chuck Arney wrote:
A 64-bit address is only ambiguous when the high word is zero and the high
bit of the low word is on. When the high word is non-zero all 32 bits of the
low word can address storage locations without ambiguity.
I'm not sure why you're even
On Tue, 4 Nov 2014 20:27:09 -0700 Paul Gilmartin
0014e0e4a59b-dmarc-requ...@listserv.uga.edu wrote:
:On 2014-11-04, at 19:25, Chuck Arney wrote:
: A 64-bit address is only ambiguous when the high word is zero and the high
bit of the low word is on. When the high word is non-zero all 32
30 matches
Mail list logo
