ds one.
sas
On 11/6/2014 11:07, Dale R. Smith wrote:
On Wed, 5 Nov 2014 14:19:59 -0700, Paul Gilmartin wrote:
On 2014-11-05, at 13:11, Walt Farrell wrote:
On Wed, 5 Nov 2014 12:03:51 -0700, Paul Gilmartin wrote:
Nevertheless, as long as z/OS and z/VSE exclude 2GiB <= address <
On Wed, 5 Nov 2014 14:19:59 -0700, Paul Gilmartin wrote:
>On 2014-11-05, at 13:11, Walt Farrell wrote:
>
>> On Wed, 5 Nov 2014 12:03:51 -0700, Paul Gilmartin
>> wrote:
>>
>>> Nevertheless, as long as z/OS and z/VSE exclude 2GiB <= address < 4GiB,
>
>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
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 Sha
On Wed, 5 Nov 2014 14:19:59 -0700, Paul Gilmartin 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 mentioned IARV64 and
On Wed, 5 Nov 2014 18:07:17 -0500, Tony Harminc 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_ give you back
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 l
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 d
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
On 2014-11-05, at 13:11, Walt Farrell wrote:
> On Wed, 5 Nov 2014 12:03:51 -0700, Paul Gilmartin
> 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
On 5 November 2014 16:32, John McKown wrote:
> On Wed, Nov 5, 2014 at 8:57 AM, Steve Smith 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 a
t; :-) )
> > >
> > This been discussed, tediously, in these lists. The statement, including
> > from some IBM employees, perhaps unofficial, is that the BAR is an
> > infinitesimal boundary immediately below 2GiB. Any address >= 2GiB
> > is considered *above*, never in
On Wed, 5 Nov 2014 12:03:51 -0700, Paul Gilmartin 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
oyees, 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
he 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?
-- gil
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 bi
On Wed, Nov 5, 2014 at 8:57 AM, Steve Smith 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 doesn't have any su
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 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 n
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 Opp
... sorry, wrong list ...
Original-Nachricht
Betreff:Fwd: Re: 2GiB <= address < 4GiB
Datum: Wed, 05 Nov 2014 09:32:47 +0100
Von:Bernd Oppolzer
An: IBM Mainframe Discussion List
... should be "storage access" instead of "storage addres
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
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
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 di
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 d
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 addre
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
> <
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 on
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 i
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 misunders
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? I
31 matches
Mail list logo