Re: VSCR (was: Examples of getbuf and build usage)
On Mon, 3 Jun 2013 11:02:10 -0500, Paul Gilmartin wrote: On Mon, 3 Jun 2013 10:08:19 -0500, Tom Marchant wrote: Why do you continue to refer to the area between 2GB and 4GB as Within the bar? While it is true that some early presentations depicted the bar as having a thickness of 2 GB, AFAIK, it was never documented that way in any IBM manual. Rather, the manuals describe the area above 2 GB as above the bar. The construct is such a convenient abbreviation that I see little reason to discontinue its historic use. Accuracy? Can you show me a reference in any manual indicating that it has ever been different from the two quotes that I provided in my previous post? Both of those quotes were both taken from release 2 editions of the manuals. Why is it useful to single out part of the storage above the bar as being within the bar? Do you similarly claim that the 16 MB line has thickness because you can't allocate any of the storage where the nucleus resides? The manuals say that addresses above 2 GB are above the bar. I've yet to see any manual that says that the bar has thickness. There was considerable discussion about this here in 2010 and 2011. Many claimed that the bar has a thickness of 2 GB. At least one person claimed that above the bar meant data above 4 GB. I have seen nothing in any IBM manual to substantiate any of this. There were non-specific references to a SHARE presentation that showed the bar being from 2 GB to 4 GB. SHARE presentations are not official documentation. AFAICT, the documentation for storage above the bar was introduced with release 2 and has always said that the bar is at 2 GB. Everything above 2 GB is above the bar. If there is any documentation to support another meaning of the term, I would like to see it. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: VSCR (was: Examples of getbuf and build usage)
There was a period during which virtual storage immediately above the bar was not allocated. The rationale for not doing so was that incorrect AMODE(31) address arithmetic could yield values in that range. I have no personal experience of the usefulness of this convention, but several contributors here whose judgment I trust noted that they had found it helpful. In any case this issue has now been parameterized. It also perhaps bears repeating that we are dealing here with AMODE(64) virtual storage, of which, for now at least, we have what may properly be called a plethora. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: VSCR (was: Examples of getbuf and build usage)
It appears that IBM's intent in defining the bar was to make it equal to the point where 31-bit addressing was no longer possible and any further addressability required 32 or more bits. Bill Fairchild Franklin, TN - Original Message - From: Tom Marchant m42tom-ibmm...@yahoo.com To: IBM-MAIN@LISTSERV.UA.EDU Sent: Tuesday, June 4, 2013 2:51:22 PM Subject: Re: VSCR (was: Examples of getbuf and build usage) On Mon, 3 Jun 2013 11:02:10 -0500, Paul Gilmartin wrote: On Mon, 3 Jun 2013 10:08:19 -0500, Tom Marchant wrote: Why do you continue to refer to the area between 2GB and 4GB as Within the bar? While it is true that some early presentations depicted the bar as having a thickness of 2 GB, AFAIK, it was never documented that way in any IBM manual. Rather, the manuals describe the area above 2 GB as above the bar. The construct is such a convenient abbreviation that I see little reason to discontinue its historic use. Accuracy? Can you show me a reference in any manual indicating that it has ever been different from the two quotes that I provided in my previous post? Both of those quotes were both taken from release 2 editions of the manuals. Why is it useful to single out part of the storage above the bar as being within the bar? Do you similarly claim that the 16 MB line has thickness because you can't allocate any of the storage where the nucleus resides? The manuals say that addresses above 2 GB are above the bar. I've yet to see any manual that says that the bar has thickness. There was considerable discussion about this here in 2010 and 2011. Many claimed that the bar has a thickness of 2 GB. At least one person claimed that above the bar meant data above 4 GB. I have seen nothing in any IBM manual to substantiate any of this. There were non-specific references to a SHARE presentation that showed the bar being from 2 GB to 4 GB. SHARE presentations are not official documentation. AFAICT, the documentation for storage above the bar was introduced with release 2 and has always said that the bar is at 2 GB. Everything above 2 GB is above the bar. If there is any documentation to support another meaning of the term, I would like to see it. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: VSCR (was: Examples of getbuf and build usage)
Yes and yes again. I suspect that musical chairs was more important than denotation here: Since 'line' was unavailable because already in use, 'bar' was chosen--well chosen in my view--to disambiguate the demarcations of AMODE(64) and AMODE(31) address spaces. John Gilmore, Ashland, MA 01721 - USA -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: VSCR (was: Examples of getbuf and build usage)
On Mon, 3 Jun 2013 09:28:07 -0500, Paul Gilmartin wrote: I understand that some of Java has migrated to within the bar Why do you continue to refer to the area between 2GB and 4GB as Within the bar? While it is true that some early presentations depicted the bar as having a thickness of 2 GB, AFAIK, it was never documented that way in any IBM manual. Rather, the manuals describe the area above 2 GB as above the bar. For example, the Extended Addressability Guide for z/OS release 2 has this definition of the bar: quote bar. A virtual line that marks the 2-gigabyte address in a 64-bit address space. It separates virtual storage below the 2-gigabyte address (called below the bar) from virtual storage above the 2-gigabyte line (called above the bar). /quote And in the description of the IARV64 macro in the Assembler Services Guide for z/OS release 2 there is this description: quote The two gigabyte address in the address space is marked by a virtual line called the bar. The bar separates storage below the two gigabyte address, called below the bar, from storage above the two gigabyte address, called above the bar. /quote In any case, the area that has been reserved for Java is (IIRC) from 2GB to 32 GB, well beyond 4 GB. in order to employ 32-bit addressing without triggering further below the bar VSCR. There is no such thing as 32-bit addressing. Addresses in z/Architecture are either 24, 31 or 64 bits. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: VSCR (was: Examples of getbuf and build usage)
On Mon, 3 Jun 2013 10:08:19 -0500, Tom Marchant wrote: Why do you continue to refer to the area between 2GB and 4GB as Within the bar? While it is true that some early presentations depicted the bar as having a thickness of 2 GB, AFAIK, it was never documented that way in any IBM manual. Rather, the manuals describe the area above 2 GB as above the bar. The construct is such a convenient abbreviation that I see little reason to discontinue its historic use. In any case, the area that has been reserved for Java is (IIRC) from 2GB to 32 GB, well beyond 4 GB. I stand corrected. ITYM 2GiB to 32GiB. in order to employ 32-bit addressing without triggering further below the bar VSCR. It's an interpreter. An interpreter can use whatever representation of addresses it chooses. Rexx, for example, represents addresses as hexadecimal display values of variable length. But, yes, now that you've reminded me, 32GiB requires larger addresses than 32 bits. (Probably. If an interpreter were make its smallest unit of addressable storage 8 bytes, it could still address 32GiB with 32 bit addresses. I doubt that Java is implemented in that fashion.) -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: VSCR (was: Examples of getbuf and build usage)
DB2, IMS and CICS have already done considerable work moving stuff from 31- to 64-Bit, to name just three products. Certainly in the case of DB2 it was vital. For CICS becoming more so. Cheers, Martin Martin Packer, zChampion, Principal Systems Investigator, Worldwide Banking Center of Excellence, IBM +44-7802-245-584 email: martin_pac...@uk.ibm.com Twitter / Facebook IDs: MartinPacker Blog: https://www.ibm.com/developerworks/mydeveloperworks/blogs/MartinPacker From: Paul Gilmartin paulgboul...@aim.com To: IBM-MAIN@listserv.ua.edu, Date: 06/03/2013 03:28 PM Subject:VSCR (was: Examples of getbuf and build usage) Sent by:IBM Mainframe Discussion List IBM-MAIN@listserv.ua.edu On Mon, 3 Jun 2013 08:46:24 -0400, John Gilmore wrote: (Above-the-bar VSCR projects may be in the womb of time, but I judge that their gestation period will be very long.) A plausible judgment. But how about in between? Is VSCR below the bar but above the line looming? I'd expect a motivator to be LPA. How big is LPA getting in some shops? I understand that some of Java has migrated to within the bar in order to employ 32-bit addressing without triggering further below the bar VSCR. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: VSCR (was: Examples of getbuf and build usage)
On Mon, 2013-06-03 at 11:02 -0500, Paul Gilmartin wrote: (Probably. If an interpreter were make its smallest unit of addressable storage 8 bytes, it could still address 32GiB with 32 bit addresses. I doubt that Java is implemented in that fashion.) The IBM Java implementation does precisely this. Objects all are doubleword aligned, so the low-order three bits of a 32-bit address are zero. If you enable compressed references then 64-bit pointers are right-shifted into 32-bit words. (As you note this will only work for addresses below 32GiB.) It's a big win for Java heap space, because 64-bit pointers increase object size approximately 60% per Marcel Mitran. See his IBM Java on System z presentation at: http://www-06.ibm.com/software/jp/zseries/events/language2011/download/pdf/02_e.pdf -- David Andrews A. Duda Sons, Inc. david.andr...@duda.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
