dead zone
Roland Schiradin
is the dead zone above the bar gone for all (no longer protected) or just asids
with IARV64 and USE2GTO32G=YES.
Regards and happy new year
Roland
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to list...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
Edward Jaffe
> is the dead zone above the bar gone for all (no longer protected) or just asids
> with IARV64 and USE2GTO32G=YES.
>
Only the latter case...
--
Edward E Jaffe
Phoenix Software International, Inc
831 Parkview Drive North
El Segundo, CA 90245
310-338-0400 x318
edj...@phoenixsoftware.com
http://www.phoenixsoftware.com/
McKown, John
> From: IBM Mainframe Discussion List
> [mailto:IBM-...@bama.ua.edu] On Behalf Of Edward Jaffe
> Sent: Wednesday, December 30, 2009 2:31 PM
> To: IBM-...@bama.ua.edu
> Subject: Re: dead zone
>
> Roland Schiradin wrote:
> > is the dead zone above the bar gone for all (no longer
> protected) or just asids
> > with IARV64 and USE2GTO32G=YES.
> >
>
> Only the latter case...
>
> --
> Edward E Jaffe
I found that parameter in the IARV64 macro. But I don't see anywhere that it is documented. I would guess from the question and answer, that it enables getting 64-bit storage in the 0x0000000080000000 to 0x00000000FFFFFFFF address range?
--
John McKown
Systems Engineer IV
IT
Administrative Services Group
HealthMarkets(r)
9151 Boulevard 26 * N. Richland Hills * TX 76010
(817) 255-3225 phone * (817)-961-6183 cell
john....@healthmarkets.com * www.HealthMarkets.com
Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM
Mark Zelden
<edj...@PHOENIXSOFTWARE.COM> wrote:
>Roland Schiradin wrote:
>> is the dead zone above the bar gone for all (no longer protected) or just
asids
>> with IARV64 and USE2GTO32G=YES.
>>
>
>Only the latter case...
>
I recall a session / slides at SHARE in Denver that talked about 64-bit
Java V6
using this in order to perform at (or near) the levels of 31-bit, but I can't
seem to recall what session it was nor find anything about it in the ones I
thought it may have been in. Was I dreaming? Or did someone just put
up the slides and it wasn't included in the PDF files.
The RSM function to support this came in with OA26294, which just says
"NEW FUNCTION - JAVA SUPPORT" (z/OS 1.8, 1.9 and 1.10).
--
Mark Zelden
Sr. Software and Systems Architect - z/OS Team Lead
Zurich North America / Farmers Insurance Group - ZFUS G-ITO
mailto:mark....@zurichna.com
z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/
Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html
Edward Jaffe
> I found that parameter in the IARV64 macro. But I don't see anywhere that it is documented. I would guess from the question and answer, that it enables getting 64-bit storage in the 0x0000000080000000 to 0x00000000FFFFFFFF address range?
>
I'm not sure I would refer to it at "64-bit" storage. But, you can now
acquire and free large virtual memory objects above 2G and below 4G.
--
Edward E Jaffe
Phoenix Software International, Inc
831 Parkview Drive North
El Segundo, CA 90245
310-338-0400 x318
edj...@phoenixsoftware.com
http://www.phoenixsoftware.com/
----------------------------------------------------------------------
McKown, John
> From: IBM Mainframe Discussion List
> [mailto:IBM-...@bama.ua.edu] On Behalf Of Edward Jaffe
> Sent: Wednesday, December 30, 2009 3:10 PM
> To: IBM-...@bama.ua.edu
> Subject: Re: dead zone
>
> > I found that parameter in the IARV64 macro. But I don't see
> anywhere that it is documented. I would guess from the
> question and answer, that it enables getting 64-bit storage
> in the 0x0000000080000000 to 0x00000000FFFFFFFF address range?
> >
>
> I'm not sure I would refer to it at "64-bit" storage. But,
> you can now
> acquire and free large virtual memory objects above 2G and below 4G.
>
> --
> Edward E Jaffe
I see why it is not, technically, 64 bit storage. But the program must be AMODE(64) in order to address it. right?
And you likely could __NOT__ use it for parms to be passed to other programs or system services, even in AMODE(64). Hum, to me, for me, fairly useless.
--
John McKown
Systems Engineer IV
IT
Administrative Services Group
HealthMarkets(r)
9151 Boulevard 26 * N. Richland Hills * TX 76010
(817) 255-3225 phone * (817)-961-6183 cell
john....@healthmarkets.com * www.HealthMarkets.com
Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM
----------------------------------------------------------------------
Edward Jaffe
> I see why it is not, technically, 64 bit storage. But the program must be AMODE(64) in order to address it. right?
>
Good point! The storage is not accessible to 31-bit programs. There is
no 32-bit mode!
--
Edward E Jaffe
Phoenix Software International, Inc
831 Parkview Drive North
El Segundo, CA 90245
310-338-0400 x318
edj...@phoenixsoftware.com
http://www.phoenixsoftware.com/
----------------------------------------------------------------------
Binyamin Dissen
<John....@HEALTHMARKETS.COM> wrote:
:>> -----Original Message-----
:>> From: IBM Mainframe Discussion List
:>> [mailto:IBM-...@bama.ua.edu] On Behalf Of Edward Jaffe
:>> Sent: Wednesday, December 30, 2009 3:10 PM
:>> To: IBM-...@bama.ua.edu
:>> Subject: Re: dead zone
:>> McKown, John wrote:
:>> > I found that parameter in the IARV64 macro. But I don't see
:>> anywhere that it is documented. I would guess from the
:>> question and answer, that it enables getting 64-bit storage
:>> in the 0x0000000080000000 to 0x00000000FFFFFFFF address range?
:>> I'm not sure I would refer to it at "64-bit" storage. But,
:>> you can now
:>> acquire and free large virtual memory objects above 2G and below 4G.
:>I see why it is not, technically, 64 bit storage. But the program must be AMODE(64) in order to address it. right?
Yes.
:>And you likely could __NOT__ use it for parms to be passed to other programs or system services, even in AMODE(64). Hum, to me, for me, fairly useless.
Why not? Use a 64 bit pointer.
The only reason the black hole was created was because the high order bit
issue where a 64 bit program passed an uncleaned 31 bit address may overlay a
different area. But if all 4 byte addresses are clean there is no reason to
not use the x'80000000'-x'FFFFFFFF' area.
--
Binyamin Dissen <bdi...@dissensoftware.com>
http://www.dissensoftware.com
Director, Dissen Software, Bar & Grill - Israel
Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.
I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.
Mark Zelden
<John....@HEALTHMARKETS.COM> wrote:
>
>I see why it is not, technically, 64 bit storage.
It's 32-bit storage.
>But the program must be AMODE(64) in order to address it. right?
I suppose (along with the supporting code / PTFs / bit in the RCE set).
>And you likely could __NOT__ use it for parms to be passed to other
programs or system services, even in AMODE(64). Hum, to me, for me, fairly
useless.
>
This is where some doc on the clever usage of this storage from Java would
come in handy.
Speaking of Java... and my last post about this. Maybe it was a special
test version of Java 64-bit and the support isn't there yet? I did a quick
search and came up empty.
Mark
--
Mark Zelden
Sr. Software and Systems Architect - z/OS Team Lead
Zurich North America / Farmers Insurance Group - ZFUS G-ITO
mailto:mark....@zurichna.com
z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/
Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html
----------------------------------------------------------------------
Scott Rowe
>>> Mark Zelden <mark....@ZURICHNA.COM> 12/30/09 4:45 PM >>>
It's 32-bit storage.
CONFIDENTIALITY/EMAIL NOTICE: The material in this transmission contains confidential and privileged information intended only for the addressee. If you are not the intended recipient, please be advised that you have received this material in error and that any forwarding, copying, printing, distribution, use or disclosure of the material is strictly prohibited. If you have received this material in error, please (i) do not read it, (ii) reply to the sender that you received the message in error, and (iii) erase or destroy the material. Emails are not secure and can be intercepted, amended, lost or destroyed, or contain viruses. You are deemed to have accepted these risks if you communicate with us by email. Thank you.
Mark Zelden
>I think the session you are referring to was Bob Rogers', maybe the goody bag?
>
Checked that one. Also checked opening / hot topics for MVS, EWCP and
John Eells's z/OS 1.11 presentation. There was a Java update session,
but I wasn't at it. Nor is the presentation on the SHARE web site.
Tom Marchant
>On Wed, 30 Dec 2009 15:20:25 -0600, McKown, John wrote:
>
>>
>>I see why it is not, technically, 64 bit storage.
>
>It's 32-bit storage.
What do you mean by that, Mark?
AFAIK, when someone refers to storage as "64-bit", they are speaking of the
addressing mode required to address it. Similarly, "24-bit" storage or
"31-bit" storage refers to the minimum addressing mode required to address it.
You wouldn't refer to PSA as 10-bit storage, would you?
You can't run z/OS on a 360-67. <g,d,r>
--
Tom Marchant
Mark Zelden
wrote:
>On Wed, 30 Dec 2009 15:45:53 -0600, Mark Zelden wrote:
>
>>On Wed, 30 Dec 2009 15:20:25 -0600, McKown, John wrote:
>>
>>>
>>>I see why it is not, technically, 64 bit storage.
>>
>>It's 32-bit storage.
>
>What do you mean by that, Mark?
It's not 31-bit and it isn't "64-bit" either. I was trying to be cute.
I meant to put a smiley after that sentence.
Mark
--
Mark Zelden
Sr. Software and Systems Architect - z/OS Team Lead
Zurich North America / Farmers Insurance Group - ZFUS G-ITO
mailto:mark....@zurichna.com
z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/
Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html
>
Paul Gilmartin
>>
>> Roland Schiradin wrote:
>> > with IARV64 and USE2GTO32G=YES.
>
>I found that parameter in the IARV64 macro. But I don't see anywhere that it is documented. I would guess from the question and answer, that it enables getting 64-bit storage in the 0x0000000080000000 to 0x00000000FFFFFFFF address range?
>
and 0x00000007 FFFFFFFF [2 GiB to 32 GiB). But I had no idea there was so
large a hole, nor what the rationale for it might be.
-- gil
Scott Rowe
>>> Mark Zelden <mark....@ZURICHNA.COM> 12/30/09 5:09 PM >>>
On Wed, 30 Dec 2009 16:50:43 -0500, Scott Rowe <Scott...@JOANN.COM> wrote:
>I think the session you are referring to was Bob Rogers', maybe the goody bag?
>
Checked that one. Also checked opening / hot topics for MVS, EWCP and
John Eells's z/OS 1.11 presentation. There was a Java update session,
but I wasn't at it. Nor is the presentation on the SHARE web site.
Mark
--
Mark Zelden
Sr. Software and Systems Architect - z/OS Team Lead
Zurich North America / Farmers Insurance Group - ZFUS G-ITO
mailto:mark....@zurichna.com
z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/
Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to list...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
CONFIDENTIALITY/EMAIL NOTICE: The material in this transmission contains confidential and privileged information intended only for the addressee. If you are not the intended recipient, please be advised that you have received this material in error and that any forwarding, copying, printing, distribution, use or disclosure of the material is strictly prohibited. If you have received this material in error, please (i) do not read it, (ii) reply to the sender that you received the message in error, and (iii) erase or destroy the material. Emails are not secure and can be intercepted, amended, lost or destroyed, or contain viruses. You are deemed to have accepted these risks if you communicate with us by email. Thank you.
----------------------------------------------------------------------
Edward Jaffe
> Checked that one. Also checked opening / hot topics for MVS, EWCP and
> John Eells's z/OS 1.11 presentation. There was a Java update session,
> but I wasn't at it. Nor is the presentation on the SHARE web site.
>
Could it have been a presentation you saw at zBLC?
--
Edward E Jaffe
Phoenix Software International, Inc
831 Parkview Drive North
El Segundo, CA 90245
310-338-0400 x318
edj...@phoenixsoftware.com
http://www.phoenixsoftware.com/
----------------------------------------------------------------------
Peter Relson
use only.
The prolog of macro IARV64 confirms this, showing the classification of
USE2GTO32G as "NONE"
>This is where some doc on the clever usage of this storage from Java
>would come in handy.
Handy for whom?
-- Those who want to understand the internals of Java? Yes.
-- Anyone else? To be blunt, no one who follows the rules of programming
interfaces.
Peter Relson
z/OS Core Technology Design
Shane
> Handy for whom?
> -- Those who want to understand the internals of Java? Yes.
> -- Anyone else? To be blunt, no one who follows the rules of programming
> interfaces.
All up, sounds like a pretty reasonable definition of java.
Shane ...
Mark Zelden
<edj...@PHOENIXSOFTWARE.COM> wrote:
>Mark Zelden wrote:
>> Checked that one. Also checked opening / hot topics for MVS, EWCP and
>> John Eells's z/OS 1.11 presentation. There was a Java update session,
>> but I wasn't at it. Nor is the presentation on the SHARE web site.
>>
>
>Could it have been a presentation you saw at zBLC?
>
Nope, I'm sure it was SHARE at Denver and it was an open session.
Mark
--
Mark Zelden
Sr. Software and Systems Architect - z/OS Team Lead
Zurich North America / Farmers Insurance Group - ZFUS G-ITO
mailto:mark....@zurichna.com
z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/
Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html
----------------------------------------------------------------------
Mark Zelden
>On Wed, 30 Dec 2009 14:38:01 -0600, McKown, John wrote:
>>>
>>> Roland Schiradin wrote:
>>> > with IARV64 and USE2GTO32G=YES.
>>
>>I found that parameter in the IARV64 macro. But I don't see anywhere that
it is documented. I would guess from the question and answer, that it
enables getting 64-bit storage in the 0x0000000080000000 to
0x00000000FFFFFFFF address range?
>>
>I would infer from the name that it refers to storage between 0x00000000
80000000
>and 0x00000007 FFFFFFFF [2 GiB to 32 GiB). But I had no idea there was so
>large a hole, nor what the rationale for it might be.
>
The hole is (was) only from 2G to 4G.
Mark Zelden
>The USE2GTO32G parameter is intentionally not documented. It is for IBM
>use only.
>The prolog of macro IARV64 confirms this, showing the classification of
>USE2GTO32G as "NONE"
>
>>This is where some doc on the clever usage of this storage from Java
>>would come in handy.
>
>Handy for whom?
>-- Those who want to understand the internals of Java? Yes.
>-- Anyone else? To be blunt, no one who follows the rules of programming
>interfaces.
>
Handy to this discussion and to those that want a better understanding
of z/OS internals. I think I understand what was / is being done, but I don't
want to post any misinformation. Not that I haven't done that before, I
just try not to do it intentionally. :-)
Roland Schiradin
<edj...@PHOENIXSOFTWARE.COM> wrote:
Tnx for all reply will change the display in SHOWzOS.
Roland
>Roland Schiradin wrote:
>> is the dead zone above the bar gone for all (no longer protected) or just
asids
>> with IARV64 and USE2GTO32G=YES.
>>
>
>Only the latter case...
>
----------------------------------------------------------------------
Adam Johanson
>> Checked that one. Also checked opening / hot topics for MVS, EWCP and
>> John Eells's z/OS 1.11 presentation. There was a Java update session,
>> but I wasn't at it. Nor is the presentation on the SHARE web site.
>>
>
>Could it have been a presentation you saw at zBLC?
>
> Nope, I'm sure it was SHARE at Denver and it was an open session.
I went to that presentation, it was Bob Rogers' presentation, z/OS 1.11
Sysprog Goody Bag. I found quite a bit of notes that I took from that session
on Java and the 2GB - 4GB bar.
But when I look at the presentation on the SHARE website, there's not much
mention of it and the presentation looks incomplete. There's no "adios"
or "questions?" slide and the presentation just seems to stop in the middle.
Adam Johanson
IMS Systems Programming
USAA
Mark Zelden
wrote:
>>Mark Zelden wrote:
>>> Checked that one. Also checked opening / hot topics for MVS, EWCP and
>>> John Eells's z/OS 1.11 presentation. There was a Java update session,
>>> but I wasn't at it. Nor is the presentation on the SHARE web site.
>>>
>>
>>Could it have been a presentation you saw at zBLC?
>>
>
>> Nope, I'm sure it was SHARE at Denver and it was an open session.
>
>I went to that presentation, it was Bob Rogers' presentation, z/OS 1.11
>Sysprog Goody Bag. I found quite a bit of notes that I took from that session
>on Java and the 2GB - 4GB bar.
>
>But when I look at the presentation on the SHARE website, there's not much
>mention of it and the presentation looks incomplete. There's no "adios"
>or "questions?" slide and the presentation just seems to stop in the middle.
>
>Adam Johanson
>IMS Systems Programming
>USAA
>
Thanks Adam. You're right! I looked back at my notes and the only
note next to that session is "OA26294 - dead area". I missed that
yesterday when looking through them (but I did look at the presentation
and didn't see anything).
Mark
--
Mark Zelden
Sr. Software and Systems Architect - z/OS Team Lead
Zurich North America / Farmers Insurance Group - ZFUS G-ITO
mailto:mark....@zurichna.com
z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/
Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html
----------------------------------------------------------------------
Edward Jaffe
> Thanks Adam. You're right! I looked back at my notes and the only
> note next to that session is "OA26294 - dead area". I missed that
> yesterday when looking through them (but I did look at the presentation
> and didn't see anything).
>
This just goes to show how valuable attending an on-site SHARE
presentation really is. Not everything makes it into the proceedings.
Also, I'm impressed that so many people take notes without handouts... ;-)
--
Edward E Jaffe
Phoenix Software International, Inc
831 Parkview Drive North
El Segundo, CA 90245
310-338-0400 x318
edj...@phoenixsoftware.com
http://www.phoenixsoftware.com/
----------------------------------------------------------------------
Steve Samson
talking about virtual storage here, not real. There is no hole or 'dead
zone' in real storage.
The "bar" is a thick one, from 2g to 4g, "sacrificed" to avoid a
somewhat unlikely compatibility exposure. Undisciplined use of the
high-order bit in 31-bit addresses could have led to unexpected results.
The thick bar avoids such a problem. Considering the vast magnitude of
64-bit virtual addresses, why should anyone care or do anything to
circumvent the omitted address range?
Anyway, Happy New Year to all!
Steve Samson
Mark Zelden
<edj...@PHOENIXSOFTWARE.COM> wrote:
>Mark Zelden wrote:
>> Thanks Adam. You're right! I looked back at my notes and the only
>> note next to that session is "OA26294 - dead area". I missed that
>> yesterday when looking through them (but I did look at the presentation
>> and didn't see anything).
>>
>
>This just goes to show how valuable attending an on-site SHARE
>presentation really is. Not everything makes it into the proceedings.
>
>Also, I'm impressed that so many people take notes without handouts... ;-)
>
I understand why there aren't handouts for most sessions now, but I
take much better notes with them and since the context is around the
note, they make more sense and of course there is much less to write
and you can figure it out easier when you are looking at it 6 months
later.
My notes this past SHARE consisted of the day, time, session number,
session name and sometimes nothing after that other than an APAR
reference or "keyword" that I thought would jog my memory later
on.
Mark
--
Mark Zelden
Sr. Software and Systems Architect - z/OS Team Lead
Zurich North America / Farmers Insurance Group - ZFUS G-ITO
mailto:mark....@zurichna.com
z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/
Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html
Mark
Ed Finnell
In a message dated 12/31/2009 10:42:48 A.M. Central Standard Time,
mark....@ZURICHNA.COM writes:
My notes this past SHARE consisted of the day, time, session number,
session name and sometimes nothing after that other than an APAR
reference or "keyword" that I thought would jog my memory later
on.
>>
Probably a .99 App on your droid?
Scott Rowe
>>> Mark Zelden <mark....@ZURICHNA.COM> 12/31/09 9:02 AM >>>
On Wed, 30 Dec 2009 22:33:51 -0800, Edward Jaffe
<edj...@PHOENIXSOFTWARE.COM> wrote:
>
>Could it have been a presentation you saw at zBLC?
>
Nope, I'm sure it was SHARE at Denver and it was an open session.
Mark
--
Mark Zelden
Sr. Software and Systems Architect - z/OS Team Lead
Zurich North America / Farmers Insurance Group - ZFUS G-ITO
mailto:mark....@zurichna.com
z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/
Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to list...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
CONFIDENTIALITY/EMAIL NOTICE: The material in this transmission contains confidential and privileged information intended only for the addressee. If you are not the intended recipient, please be advised that you have received this material in error and that any forwarding, copying, printing, distribution, use or disclosure of the material is strictly prohibited. If you have received this material in error, please (i) do not read it, (ii) reply to the sender that you received the message in error, and (iii) erase or destroy the material. Emails are not secure and can be intercepted, amended, lost or destroyed, or contain viruses. You are deemed to have accepted these risks if you communicate with us by email. Thank you.
----------------------------------------------------------------------
Edward Jaffe
> My notes this past SHARE consisted of the day, time, session number,
> session name and sometimes nothing after that other than an APAR
> reference or "keyword" that I thought would jog my memory later
> on.
>
How's that working for you? :-)
--
Edward E Jaffe
Phoenix Software International, Inc
831 Parkview Drive North
El Segundo, CA 90245
310-338-0400 x318
edj...@phoenixsoftware.com
http://www.phoenixsoftware.com/
----------------------------------------------------------------------
Mark Zelden
<edj...@PHOENIXSOFTWARE.COM> wrote:
>Mark Zelden wrote:
>> My notes this past SHARE consisted of the day, time, session number,
>> session name and sometimes nothing after that other than an APAR
>> reference or "keyword" that I thought would jog my memory later
>> on.
>>
>
>How's that working for you? :-)
>
:-)
Wouldn't have been so bad if I had actually seen what I wrote, but you
can't text search hand written paper (at least without scanning it, which
wouldn't be able to read my chicken scratch anyway). The last few SHAREs
I was at, I also took these type of notes on my laptop, but most of the
rooms I was in at Denver didn't have tables and I decided not to use it.
My plan was to re-write those notes in electronic format right after SHARE
while my memory was fresh. yeah right...
Mark
--
Mark Zelden
Sr. Software and Systems Architect - z/OS Team Lead
Zurich North America / Farmers Insurance Group - ZFUS G-ITO
mailto:mark....@zurichna.com
z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/
Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html
----------------------------------------------------------------------
Anne & Lynn Wheeler
> The "bar" is a thick one, from 2g to 4g, "sacrificed" to avoid a
> somewhat unlikely compatibility exposure. Undisciplined use of the
> high-order bit in 31-bit addresses could have led to unexpected
> results. The thick bar avoids such a problem. Considering the vast
> magnitude of 64-bit virtual addresses, why should anyone care or do
> anything to circumvent the omitted address range?
one of the difference between virtual memory support on 360/67 (both
24bit & *32*bit virtual address modes) and later 370xa (on 3081).
--
40+yrs virtualization experience (since Jan68), online at home since Mar1970
Edward Jaffe
>> The "bar" is a thick one, from 2g to 4g, "sacrificed" to avoid a
>> somewhat unlikely compatibility exposure. Undisciplined use of the
>> high-order bit in 31-bit addresses could have led to unexpected
>> results. The thick bar avoids such a problem. Considering the vast
>> magnitude of 64-bit virtual addresses, why should anyone care or do
>> anything to circumvent the omitted address range?
>>
The z/OS RSM developers introduced functionality to allow Java to
acquire storage within the previously "thick" bar for performance reasons.
Paul Gilmartin
>
>The z/OS RSM developers introduced functionality to allow Java to
>acquire storage within the previously "thick" bar for performance reasons.
>
I'm still intrigued that the (undocumented) option's name
contains the substring "32G". Is 32GiB the size of a particular
granule in 64-bit storage management? Or might the "32" refer
to a fictitious "32-bit" addressing capability?
--gil
Don Poitras
> On Fri, 1 Jan 2010 08:41:53 -0800, Edward Jaffe wrote:
> >
> >The z/OS RSM developers introduced functionality to allow Java to
> >acquire storage within the previously "thick" bar for performance reasons.
> >
> I would guess, economy in page and segment tables?
> I'm still intrigued that the (undocumented) option's name
> contains the substring "32G". Is 32GiB the size of a particular
> granule in 64-bit storage management? Or might the "32" refer
> to a fictitious "32-bit" addressing capability?
> --gil
At some release 64-bit LE moved the CAA and other control blocks from
starting at 4G to 32G.
--
Don Poitras - SAS Development - SAS Institute Inc. - SAS Campus Drive
sas...@sas.com (919) 531-5637 Cary, NC 27513
Jim Mulder
07:27:20 PM:
Mainframe Discussion List
>
> In article <LISTSERV%20100101110...@BAMA.UA.EDU> you wrote:
> > On Fri, 1 Jan 2010 08:41:53 -0800, Edward Jaffe wrote:
> > >
> > >The z/OS RSM developers introduced functionality to allow Java to
> > >acquire storage within the previously "thick" bar for performance
reasons.
> > >
> > I would guess, economy in page and segment tables?
I was told that compressed pointers for storage below 32GB fit
into a smaller space, so more compressed pointers fit in a cache
line, leading to more effective cache utilization. Performance is
all about the caches these days. I am not a Java person. I don't
know what a compressed pointer is.
> > I'm still intrigued that the (undocumented) option's name
> > contains the substring "32G". Is 32GiB the size of a particular
> > granule in 64-bit storage management? Or might the "32" refer
> > to a fictitious "32-bit" addressing capability?
>
The range from 2GB to 32GB is set aside for a particular intended
user, which is the JVM.
> At some release 64-bit LE moved the CAA and other control blocks from
> starting at 4G to 32G.
I doubt that LE changed anything. Due to the RSM change, IARV64
is returning an address of 32GB instead of 4GB when LE creates the
first memory object in the address space.
Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY
McKown, John
> From: IBM Mainframe Discussion List
> [mailto:IBM-...@bama.ua.edu] On Behalf Of Edward Jaffe
> Sent: Friday, January 01, 2010 10:42 AM
> To: IBM-...@bama.ua.edu
> Subject: Re: dead zone
>
> Steve Samson <ssa...@dc.rr.com> writes:
> >> The "bar" is a thick one, from 2g to 4g, "sacrificed" to avoid a
> >> somewhat unlikely compatibility exposure. Undisciplined use of the
> >> high-order bit in 31-bit addresses could have led to unexpected
> >> results. The thick bar avoids such a problem. Considering the vast
> >> magnitude of 64-bit virtual addresses, why should anyone care or do
> >> anything to circumvent the omitted address range?
> >>
>
> The z/OS RSM developers introduced functionality to allow Java to
> acquire storage within the previously "thick" bar for
> performance reasons.
>
> --
> Edward E Jaffe
Hum, that is very curious to me. But I guess it expands the available/addressable storage without switching from AMODE(31) to AMODE(64) and back. Java is a storage pig. And too much stuff in z/OS still requires AMODE(31) storage (like DCBs et al.)
--
John McKown
Systems Engineer IV
IT
Administrative Services Group
HealthMarkets(r)
9151 Boulevard 26 * N. Richland Hills * TX 76010
(817) 255-3225 phone * (817)-961-6183 cell
john....@healthmarkets.com * www.HealthMarkets.com
Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM
Binyamin Dissen
<John....@HEALTHMARKETS.COM> wrote:
:>> -----Original Message-----
:>> From: IBM Mainframe Discussion List
:>> [mailto:IBM-...@bama.ua.edu] On Behalf Of Edward Jaffe
:>> Sent: Friday, January 01, 2010 10:42 AM
:>> To: IBM-...@bama.ua.edu
:>> Subject: Re: dead zone
:>> Steve Samson <ssa...@dc.rr.com> writes:
:>> >> The "bar" is a thick one, from 2g to 4g, "sacrificed" to avoid a
:>> >> somewhat unlikely compatibility exposure. Undisciplined use of the
:>> >> high-order bit in 31-bit addresses could have led to unexpected
:>> >> results. The thick bar avoids such a problem. Considering the vast
:>> >> magnitude of 64-bit virtual addresses, why should anyone care or do
:>> >> anything to circumvent the omitted address range?
:>> The z/OS RSM developers introduced functionality to allow Java to
:>> acquire storage within the previously "thick" bar for
:>> performance reasons.
:>Hum, that is very curious to me. But I guess it expands the available/addressable storage without switching from AMODE(31) to AMODE(64) and back. Java is a storage pig. And too much stuff in z/OS still requires AMODE(31) storage (like DCBs et al.)
The storage between 2g and 4g is NOT accessible in 31 bit mode.
--
Binyamin Dissen <bdi...@dissensoftware.com>
http://www.dissensoftware.com
Director, Dissen Software, Bar & Grill - Israel
Should you use the mailblocks package and expect a response from me,
you should preauthorize the dissensoftware.com domain.
I very rarely bother responding to challenge/response systems,
especially those from irresponsible companies.
McKown, John
> From: IBM Mainframe Discussion List
> [mailto:IBM-...@bama.ua.edu] On Behalf Of Binyamin Dissen
> Sent: Monday, January 04, 2010 7:50 AM
> To: IBM-...@bama.ua.edu
> Subject: Re: dead zone
>
>> :>Hum, that is very curious to me. But I guess it expands the
>> available/addressable storage without switching from
>> AMODE(31) to AMODE(64) and back. Java is a storage pig. And
>> too much stuff in z/OS still requires AMODE(31) storage (like
>> DCBs et al.)
>
> The storage between 2g and 4g is NOT accessible in 31 bit mode.
>
> --
> Binyamin Dissen <bdi...@dissensoftware.com>
You're right! So, why bother and how does it improve performance? I guess we'll never know. It is likely "proprietary". Another reason that z/OS is dying. IBM wants it to be as closed as software on the "i". Tell the "unwashed masses" nothing. And make the vendors pay through the nose for that information. Lyrics "money, money, MONEY."
http://www.lyricsondemand.com/tvthemes/apprenticelyrics.html
Still brain dead from New Years, I guess.
--
John McKown
Systems Engineer IV
IT
Administrative Services Group
HealthMarkets(r)
9151 Boulevard 26 * N. Richland Hills * TX 76010
(817) 255-3225 phone * (817)-961-6183 cell
john....@healthmarkets.com * www.HealthMarkets.com
Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM
----------------------------------------------------------------------
Jim Phoenix
>> The storage between 2g and 4g is NOT accessible in 31 bit mode.
>>
>> --
>> Binyamin Dissen <bdi...@dissensoftware.com>
>>
>
> You're right! So, why bother and how does it improve performance? I guess we'll never know. It is likely "proprietary".
>
> John McKown
> Systems Engineer IV
> IT
>
> Administrative Services Group
>
>
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to list...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html
>
>
>
translating the virtual address to a real address on a TLB miss.
Doesn't have to reference the region-table entry.
--
| Jim Phoenix | Voice: (310) 338-0400 x316 |
| Senior Software Developer | Fax: (310) 338-0801 |
| Phoenix Software International | Alt fax: (310) 337-2685 |
| 831 Parkview Drive North | jimph...@phoenixsoftware.com |
| El Segundo, CA 90245 | http://www.phoenixsoftware.com |
Opinions expressed by this individual are not necessarily those of the
Company.