Re: CSA 'above the bar'
In [EMAIL PROTECTED], on 11/07/2007 at 10:02 AM, Edward Jaffe [EMAIL PROTECTED] said: This is simply not true!! Want to bet? The two AMODE bits (BA EA) are in the PSW, not in address words. There are specific instructions that interpret bit 0 of the 32-bit[1] branch address as AMODE31. See your friendly neighborhood PoOps for switching between AMODE24 and AMODE31. [1] In AMODE64 it would be bit 32, and I haven't checked how, e.g., BSM, behave in that mode. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CSA 'above the bar'
In [EMAIL PROTECTED], on 11/07/2007 at 12:38 PM, Eric Bielefeld [EMAIL PROTECTED] said: Isn't that what they said when MVS first came out? I don't know what they said, but certainly I never said that 2 GiB was near infinite. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CSA 'above the bar'
In [EMAIL PROTECTED], on 11/06/2007 at 02:12 PM, R.S. [EMAIL PROTECTED] said: However I don't understand the reason why any bit in any 24-bit address could mess someting in 64-bit addressing mode. What you don't understand is that typically a 24-bit address is not used by just 24-bit code. Once the AMODE 24 code passes an address to code in AMODE 64, there are new issues. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CSA 'above the bar'
Tom Chris, Haven't looked at the thread for some time... a bit late now... What I meant was this... The bit signaling the line is x'8000' which is the only reason why x' 8000' - x' 0001' is not addressable. IBM decided that using the Highest bit to do this signaling... the wastage I was referring to was virtual storage... which is probably not a wastage, except if it means that you might have to go to ' ' a few years earlier because you have thrown away the addressability of the width of the bar... Because surely there is some sort of a cost involved in programming the addressability. My thinking, right or wrong was that if they used the lowest bit to do the signaling, they would have lost addressability to less. Regards Herbie -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Tom Marchant Sent: 08 November 2007 07:43 nm To: IBM-MAIN@BAMA.UA.EDU Subject: Re: CSA 'above the bar' On Thu, 8 Nov 2007 10:14:42 -, Van Dalsen, Herbie wrote: Apologies, I keep on forgetting that the '8' just signals the above the line, you and Tom and all the others are quite correct with the x'7fff', I have it now... it is a pitty that IBM did not use the lowest bit to signal the line... x'0001' for 24-bit and x'0002' for 32-bit, it would have meant less wastage. Because you would have lost the first few addresses... huh? What wastage are you talking about? I'd suggest that you read chapter 3 of the principles of operation. What do you mean about signaling the line? Are you referring to the bit in the PSW that tells the processor whether to operate in 24-bit mode or 31-bit mode? In 24-bit mode, addresses can go from 0 to x'FF'. In 31-bit mode, addresses can go from 0 to x'7FFF'. The line is simply a way of talking about storage locations that cannot be referenced in 24-bit mode In the 360 and 370 architecture (except for the 360-67), addresses were 24 bits, with a maximum possible value of FF. Because of wrap around, the bext byte after x'FF' was location 0. The 370-XA architecture allowed for 31 bit addresses. In 31-bit mode, the next byte after location x'FF' is x'100'. Note that it takes a minimum of 25 bits to represent that address. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html Elavon Financial Services Limited Registered in Ireland: Number 418442 Registered Office: Block E, 1st Floor, Cherrywood Business Park, Loughlinstown, Co. Dublin, Ireland Directors: Robert Abele (USA), John Collins, Terrance Dolan (USA), Pamela Joseph (USA), Declan Lynch, John McNally, Malcolm Towlson Elavon Financial Services Limited, trading as Elavon, is regulated by the Financial Regulator -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CSA 'above the bar'
In a message dated 11/14/2007 7:45:09 A.M. Central Standard Time, [EMAIL PROTECTED] writes: My thinking, right or wrong was that if they used the lowest bit to do the signaling, they would have lost addressability to less. The lowest bit was assigned a meaning in the mid-1960s, namely an odd address which causes a specification exception. The reason the bit is on is almost a program error, although it could conceivably be turned on to force a program interrupt for some reason. To use it now as an indication of being in 64-bit addressing mode would thus require using another bit somewhere that the microcode would interrogate to determine which of two ways to interpret the lowest bit. Programs today are still generating odd addresses all the time due to program bugs. The best way to design new function is almost always to use previously unavailable or reserved resources, rather than to assign a new meaning to an already existing resource. It happens sometimes, though, when IBM realizes that no one is using the old function any more. The amount of virtual storage wasted by the addressing hole in vanishingly insignificant when compared to the total addressing capability of 2 to the 64th power number of bytes. A rough approximation is that we have only 2 to the 63rd different bytes we can address, using virtual addresses, on z/OS. Bill Fairchild Franklin, TN ** See what's new at http://www.aol.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CSA 'above the bar'
Bill, You are probably right... the amount wasted is minimal in the 64bit scheme... Regards Herbie -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of (IBM Mainframe Discussion List) Sent: 14 November 2007 03:14 nm To: IBM-MAIN@BAMA.UA.EDU Subject: Re: CSA 'above the bar' In a message dated 11/14/2007 7:45:09 A.M. Central Standard Time, [EMAIL PROTECTED] writes: My thinking, right or wrong was that if they used the lowest bit to do the signaling, they would have lost addressability to less. The lowest bit was assigned a meaning in the mid-1960s, namely an odd address which causes a specification exception. The reason the bit is on is almost a program error, although it could conceivably be turned on to force a program interrupt for some reason. To use it now as an indication of being in 64-bit addressing mode would thus require using another bit somewhere that the microcode would interrogate to determine which of two ways to interpret the lowest bit. Programs today are still generating odd addresses all the time due to program bugs. The best way to design new function is almost always to use previously unavailable or reserved resources, rather than to assign a new meaning to an already existing resource. It happens sometimes, though, when IBM realizes that no one is using the old function any more. The amount of virtual storage wasted by the addressing hole in vanishingly insignificant when compared to the total addressing capability of 2 to the 64th power number of bytes. A rough approximation is that we have only 2 to the 63rd different bytes we can address, using virtual addresses, on z/OS. Bill Fairchild Franklin, TN ** See what's new at http://www.aol.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html Elavon Financial Services Limited Registered in Ireland: Number 418442 Registered Office: Block E, 1st Floor, Cherrywood Business Park, Loughlinstown, Co. Dublin, Ireland Directors: Robert Abele (USA), John Collins, Terrance Dolan (USA), Pamela Joseph (USA), Declan Lynch, John McNally, Malcolm Towlson Elavon Financial Services Limited, trading as Elavon, is regulated by the Financial Regulator -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CSA 'above the bar'
You are probably right... the amount wasted is minimal in the 64bit scheme... I remember when HIPERSPACEs first came out. I had a 2GB space, but everybody complained about the lowest page (4K - PSA) being unavailable. Same issue. - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CSA 'above the bar'
Ted said: I had a 2GB space, but everybody complained about the lowest page (4K - PSA) being unavailable. I believe that was a 3090E vs 3090S thing. And I thought it was DATAspaces that had that problem. The S corrected the problem., Cheers, Martin Martin Packer Performance Consultant IBM United Kingdom Ltd +44-20-8832-5167 +44-7802-245-584 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CSA 'above the bar'
(IBM Mainframe Discussion List) wrote: In a message dated 11/14/2007 7:45:09 A.M. Central Standard Time, [EMAIL PROTECTED] writes: My thinking, right or wrong was that if they used the lowest bit to do the signaling, they would have lost addressability to less. That's exactly what they have done! 64-bit pointer-defined linkage (e.g., BASSM to 64-bit mode routine) is specified by turning on bit 63 of the target address register. In this case, bit 32 (the bit that signals 31-bit pointer-defined linkage) is treated simply as part of the 64-bit target address. -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 [EMAIL PROTECTED] http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CSA 'above the bar'
In [EMAIL PROTECTED], on 11/08/2007 at 06:23 PM, Thompson, Steve [EMAIL PROTECTED] said: Actually, yes. It is address x'00' and was called PSA (but is actually absolute page 0). PSA is real address 0; it's absolute address 0 for at most one of the processors in the complex. Neither real nor absolute addresses are virtual addresses, and the mapping of virtual 0 to real 0[1] is strictly a software convention. [1] And other PSA mappings. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CSA 'above the bar'
The following message is a courtesy copy of an article that has been posted to bit.listserv.ibm-main,alt.folklore.computers as well. [EMAIL PROTECTED] (Shmuel Metz , Seymour J.) writes: PSA is real address 0; it's absolute address 0 for at most one of the processors in the complex. Neither real nor absolute addresses are virtual addresses, and the mapping of virtual 0 to real 0[1] is strictly a software convention. multiprocessor support required a unique PSA for every processor. in 360 multiprocessor, the prefix register (for every processor) contained the real address of the PSA for that processor; different processors chose different real addresses for their PSA ... so as to have a unique PSA for every processor in the complex. the real, real page zero was no longer addressable (assuming every processor chose some other real address than zero). this was modified for 370, the prefix register specified the real address of the PSA for that processor (as in 360) ... however, if the processor addressed the address in the prefix register, it would reverse translate to real page zero. as a result, the real, real page zero could be used as common communication area between all processors in the complex ... and was addressed by using the address in the processor's prefix register. http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/dz9zr003/3.7?DT=20040504121320 from above: 1. Bits 0-50 of the address, if all zeros, are replaced with bits 0-50 of the prefix. 2. Bits 0-50 of the address, if equal to bits 0-50 of the prefix, are replaced with zeros. 3. Bits 0-50 of the address, if not all zeros and not equal to bits 0-50 of the prefix, remain unchanged. ... snip ... #1 #3 was how things operated in 360 multiprocessor support; #2 was introduced with 370 multiprocessor support (modulo 360 370 were 4kbyte pages and above description is for 64bit Z and 8kbyte pages) past posts mentioning multiprocessor support and/or compareswap instruction http:/www.garlic.com/~lynn/subtopic.html#smp other recent posts in this thread: http://www.garlic.com/~lynn/2007r.html#56 CSA 'above the bar' http://www.garlic.com/~lynn/2007r.html#62 CSA 'above the bar' http://www.garlic.com/~lynn/2007r.html#64 CSA 'above the bar' http://www.garlic.com/~lynn/2007r.html#65 CSA 'above the bar' http://www.garlic.com/~lynn/2007r.html#67 CSA 'above the bar' http://www.garlic.com/~lynn/2007r.html#69 CSA 'above the bar' -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CSA 'above the bar'
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of McKown, John Sent: Wednesday, November 07, 2007 2:14 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: CSA 'above the bar' -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Mark Zelden Sent: Wednesday, November 07, 2007 2:12 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: CSA 'above the bar' You mean 640K isn't as much as I'll ever need? (No, Bill never really said it) Anymore, 640K is not enough to do Hello, World! type programs. Especially when you add in the GUI interface and all the Are You Sure? dialog boxes. Internationalization requires even more memory. SNIP Once upon a time, in a Galaxy far far away, 4K of 8bit memory allowed one to do payroll for a large company (hourly, salaried, part-time, etc.). And that was 4K for just the application. And that same 4K allowed for double entry based accounting systems. Then came the 128K machines with 8 DASD spindles and the ability to do 3 different jobs simultaneously (accounting, payroll, and compiles). One wonders how much code bloat the world can stand. Regards, Steve Thompson -- All opinions expressed by me are my own and may not necessarily reflect those of my employer. -- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CSA 'above the bar'
John, Apologies, I keep on forgetting that the '8' just signals the above the line, you and Tom and all the others are quite correct with the x'7fff', I have it now... it is a pitty that IBM did not use the lowest bit to signal the line... x'0001' for 24-bit and x'0002' for 32-bit, it would have meant less wastage. Because you would have lost the first few addresses... Wonder what the affect of that would have been on all the programs that that branch to x'0' when they go hey-wire... One more question, does this apply to real storage too, or has IBM found a different way of managing this? Regards Herbie -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Chase, John Sent: 07 November 2007 17:56 To: IBM-MAIN@BAMA.UA.EDU Subject: Re: CSA 'above the bar' -Original Message- From: IBM Mainframe Discussion List On Behalf Of Van Dalsen, Herbie John, That makes no sense to me... I thought that a 31-bit program could address x'' - 'x'0FFF' below the line, and the same above the line. I.O.W. it could go up to x'8FFF' which means x'0FFF' above ? This means that the hole is from x' 9000' - ? A 31-bit program can address from x'' through x'7FFF'. Expressed in 64-bit addressing, that range is from x'_' through x'_7FFF'. IOW, for a 31-bit program, the high halves of the 64-bit registers do not exist; they may actually contain anything and they will be ignored by 31-bit (and 24-bit) programs. A 64-bit program (amode 64) can address exactly the same range, in the same way, except that the high halves of the 64-bit registers MUST contain all binary zeroes. IN ADDITION, an amode 64 program can address from x'0001_' through x'_'. NO PROGRAM is allowed to address the space from x'_8000' through x'_', which is the bar, the hole, or whatever other name seems appropriate. See previous posts from Ed Jaffe, Peter Relson and Chris Craddock for why that is a good idea. -jc- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html Elavon Financial Services Limited Registered in Ireland: Number 418442 Registered Office: Block E, 1st Floor, Cherrywood Business Park, Loughlinstown, Co. Dublin, Ireland Directors: Robert Abele (USA), John Collins, Terrance Dolan (USA), Pamela Joseph (USA), Declan Lynch, John McNally, Malcolm Towlson Elavon Financial Services Limited, trading as Elavon, is regulated by the Financial Regulator -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CSA 'above the bar'
Last one... I have not checked this for myself yet, and probably won't have the time in the next few weeks... In theory... If I allocate 200 bytes of storage at x'7f00', and my program, the way some Cobol programs are, writes 1600 bytes there, what would the addresses be, would it jump across the 'hole' or try and write over the hole? Herbie -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Tom Marchant Sent: 07 November 2007 18:06 To: IBM-MAIN@BAMA.UA.EDU Subject: Re: CSA 'above the bar' On Wed, 7 Nov 2007 11:55:35 -0600, Chase, John wrote: NO PROGRAM is allowed to address the space from x'_8000' through x'_' ... More precisely, z/OS will not create a memory object in that range so it will never be allocated storage. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html Elavon Financial Services Limited Registered in Ireland: Number 418442 Registered Office: Block E, 1st Floor, Cherrywood Business Park, Loughlinstown, Co. Dublin, Ireland Directors: Robert Abele (USA), John Collins, Terrance Dolan (USA), Pamela Joseph (USA), Declan Lynch, John McNally, Malcolm Towlson Elavon Financial Services Limited, trading as Elavon, is regulated by the Financial Regulator -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CSA 'above the bar'
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Van Dalsen, Herbie Sent: Thursday, November 08, 2007 4:24 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: CSA 'above the bar' Last one... I have not checked this for myself yet, and probably won't have the time in the next few weeks... In theory... If I allocate 200 bytes of storage at x'7f00', and my program, the way some Cobol programs are, writes 1600 bytes there, what would the addresses be, would it jump across the 'hole' or try and write over the hole? Herbie Assuming Amode(31), then standard address wrapping from 0x7FFF to 0x, followed by a S0C4-4 abend. In amode(64), you'd get a S0C4-11? Some sort of S0C4 abend. -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology The information contained in this e-mail message may be privileged and/or confidential. It is for intended addressee(s) only. If you are not the intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication is strictly prohibited and could, in certain circumstances, be a criminal offense. If you have received this e-mail in error, please notify the sender by reply and delete this message without copying or disclosing it. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CSA 'above the bar'
Thanks -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of McKown, John Sent: 08 November 2007 04:12 nm To: IBM-MAIN@BAMA.UA.EDU Subject: Re: CSA 'above the bar' -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Van Dalsen, Herbie Sent: Thursday, November 08, 2007 4:24 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: CSA 'above the bar' Last one... I have not checked this for myself yet, and probably won't have the time in the next few weeks... In theory... If I allocate 200 bytes of storage at x'7f00', and my program, the way some Cobol programs are, writes 1600 bytes there, what would the addresses be, would it jump across the 'hole' or try and write over the hole? Herbie Assuming Amode(31), then standard address wrapping from 0x7FFF to 0x, followed by a S0C4-4 abend. In amode(64), you'd get a S0C4-11? Some sort of S0C4 abend. -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology The information contained in this e-mail message may be privileged and/or confidential. It is for intended addressee(s) only. If you are not the intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication is strictly prohibited and could, in certain circumstances, be a criminal offense. If you have received this e-mail in error, please notify the sender by reply and delete this message without copying or disclosing it. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html Elavon Financial Services Limited Registered in Ireland: Number 418442 Registered Office: Block E, 1st Floor, Cherrywood Business Park, Loughlinstown, Co. Dublin, Ireland Directors: Robert Abele (USA), John Collins, Terrance Dolan (USA), Pamela Joseph (USA), Declan Lynch, John McNally, Malcolm Towlson Elavon Financial Services Limited, trading as Elavon, is regulated by the Financial Regulator -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CSA 'above the bar'
In a message dated 11/8/2007 10:02:17 A.M. Central Standard Time, [EMAIL PROTECTED] writes: I have not checked this for myself yet, and probably won't have the time in the next few weeks... In theory... If I allocate 200 bytes of storage at x'7f00', and my program, the way some Cobol programs are, writes 1600 bytes there, what would the addresses be, would it jump across the 'hole' or try and write over the hole? The addresses of the 200 bytes (decimal number 200 is assumed) that your program allocates would be X'7F00' to X'7FC7'. If your COBOL program attempts to write 1600 (decimal assumed again) bytes beginning at X'7F00', your program would write at most the first 256 of the 1600 bytes and, when attempting to write the 257th byte, would be interrupted with a protection check program interrupt that would result in a S0C4 ABEND. I said at most because I have not yet studied the latest PoOps to know how new move instructions move bytes. And it would depend on how your program does the move. If it moves one byte per instruction in a loop, it would write 256 bytes and then ABEND. There might be another type of move instruction whose preprocessing checks the beginning and ending addresses for validity before moving the first byte, in which case your program would write zero bytes and then ABEND. Your program would try to write over the hole but would not be allowed to by the various protection mechanisms in the processor architecture. Bill Fairchild Franklin, TN ** See what's new at http://www.aol.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CSA 'above the bar'
On Thu, 8 Nov 2007 08:43:03 -0800 Edward Jaffe [EMAIL PROTECTED] wrote: :There is also a one-page hole at 7000. (Another handy :implementation choice made by your friendly-neighborhood z/OS developers!) Interesting. Is that hole documented? Is there any 24 bit virtual address which is never assigned a slot? I use X'DDnn' which tends to fail whether used in 24 bit or 31 bit, but would certainly prefer a documented answer. -- Binyamin Dissen [EMAIL PROTECTED] 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. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CSA 'above the bar'
Van Dalsen, Herbie wrote: Last one... I have not checked this for myself yet, and probably won't have the time in the next few weeks... In theory... If I allocate 200 bytes of storage at x'7f00', and my program, the way some Cobol programs are, writes 1600 bytes there, what would the addresses be, would it jump across the 'hole' or try and write over the hole? There is also a one-page hole at 7000. (Another handy implementation choice made by your friendly-neighborhood z/OS developers!) This provides a way for 31-bit or 64-bit programs to place a guaranteed bad address into an address word or register. You can see this address peppered throughout the PSA. -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 [EMAIL PROTECTED] http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CSA 'above the bar'
Thanks -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of (IBM Mainframe Discussion List) Sent: 08 November 2007 04:20 nm To: IBM-MAIN@BAMA.UA.EDU Subject: Re: CSA 'above the bar' In a message dated 11/8/2007 10:02:17 A.M. Central Standard Time, [EMAIL PROTECTED] writes: I have not checked this for myself yet, and probably won't have the time in the next few weeks... In theory... If I allocate 200 bytes of storage at x'7f00', and my program, the way some Cobol programs are, writes 1600 bytes there, what would the addresses be, would it jump across the 'hole' or try and write over the hole? The addresses of the 200 bytes (decimal number 200 is assumed) that your program allocates would be X'7F00' to X'7FC7'. If your COBOL program attempts to write 1600 (decimal assumed again) bytes beginning at X'7F00', your program would write at most the first 256 of the 1600 bytes and, when attempting to write the 257th byte, would be interrupted with a protection check program interrupt that would result in a S0C4 ABEND. I said at most because I have not yet studied the latest PoOps to know how new move instructions move bytes. And it would depend on how your program does the move. If it moves one byte per instruction in a loop, it would write 256 bytes and then ABEND. There might be another type of move instruction whose preprocessing checks the beginning and ending addresses for validity before moving the first byte, in which case your program would write zero bytes and then ABEND. Your program would try to write over the hole but would not be allowed to by the various protection mechanisms in the processor architecture. Bill Fairchild Franklin, TN ** See what's new at http://www.aol.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html Elavon Financial Services Limited Registered in Ireland: Number 418442 Registered Office: Block E, 1st Floor, Cherrywood Business Park, Loughlinstown, Co. Dublin, Ireland Directors: Robert Abele (USA), John Collins, Terrance Dolan (USA), Pamela Joseph (USA), Declan Lynch, John McNally, Malcolm Towlson Elavon Financial Services Limited, trading as Elavon, is regulated by the Financial Regulator -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CSA 'above the bar'
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Jim Mulder Sent: Thursday, November 08, 2007 6:07 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: CSA 'above the bar' IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU wrote on 11/08/2007 06:23:58 PM: SNIP Actually, no. We are talking about virtual addressability, and x'00' is certainly addressable as a 24-bit virtual address in every address space, and addresses the PSA for the processor on which the code is executing. Furthermore, absolute frame 0 is also addressable by using the SQA virtual address of the PSA for the processor on which the code is executing. This will reverse prefix to absolute 0. As of z/OS 1.5, if there was more than one CPU available at IPL time, the SQA virtual address of the a PSA will be a 31-bit ESQA address. Otherwise, it will be a 24-bit SQA address. As of MVS/XA, we always use a non-zero prefix for each online CPU, so practically speaking, MVS does not use frame absolute 0 for anything other than IPL processing and SADMP processing (SADMP only uses one CPU and uses a prefix of zero). SNIP You did say dedicated. And it certainly appears to me to be both dedicated and reserved (by architectural definition). In the MVS world, if a Problem State program attempts to modify 0xxx (where x is 0-512 decimal and regardless of the content of the current base register) and LAP is on... So it is not truly available (except to the SCP). Otherwise, as I recall [MVS environments], that page is Key0 non-fetch protected. [The above is only for non-Z architected machines. I honestly haven't read the requisite chapters in the new PoOP.] Regards, Steve Thompson -- All opinions expressed by me are my own and may not necessarily reflect those of my employer. -- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CSA 'above the bar'
IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU wrote on 11/08/2007 12:24:52 PM: On Thu, 8 Nov 2007 08:43:03 -0800 Edward Jaffe [EMAIL PROTECTED] wrote: :There is also a one-page hole at 7000. (Another handy :implementation choice made by your friendly-neighborhood z/OS developers!) Interesting. Is that hole documented? I don't know if it is documented, but it has been that way since the beginning of MVS/XA, and isn't going to change. Is there any 24 bit virtual address which is never assigned a slot? No, there is no such 24 bit virtual address. With only 4,096 pages that are 24-bit addressable, I guess we didn't want to dedicate one of them for that purpose. Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CSA 'above the bar'
IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU wrote on 11/08/2007 07:20:09 PM: -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Jim Mulder Sent: Thursday, November 08, 2007 6:07 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: CSA 'above the bar' IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU wrote on 11/08/2007 06:23:58 PM: SNIP Actually, no. We are talking about virtual addressability, and x'00' is certainly addressable as a 24-bit virtual address in every address space, and addresses the PSA for the processor on which the code is executing. Furthermore, absolute frame 0 is also addressable by using the SQA virtual address of the PSA for the processor on which the code is executing. This will reverse prefix to absolute 0. As of z/OS 1.5, if there was more than one CPU available at IPL time, the SQA virtual address of the a PSA will be a 31-bit ESQA address. Otherwise, it will be a 24-bit SQA address. As of MVS/XA, we always use a non-zero prefix for each online CPU, so practically speaking, MVS does not use frame absolute 0 for anything other than IPL processing and SADMP processing (SADMP only uses one CPU and uses a prefix of zero). SNIP You did say dedicated. And it certainly appears to me to be both dedicated and reserved (by architectural definition). In the MVS world, if a Problem State program attempts to modify 0xxx (where x is 0-512 decimal and regardless of the content of the current base register) and LAP is on... So it is not truly available (except to the SCP). Otherwise, as I recall [MVS environments], that page is Key0 non-fetch protected. [The above is only for non-Z architected machines. I honestly haven't read the requisite chapters in the new PoOP.] 7000 is always not addressible in an MVS address space in 31-bit addressing mode because MVS chooses to never back that virtual page with a real page. The original poster asked if there is any address which has the same property in 24-bit addressing mode. The answer to that question is no. That is strictly an MVS implementation question. It is not a machine architecture question. I answered the original question from the point of view of what VSM does. However, I think a program can create an a page which is not addressable in 24-bit addressing mode by doing a GETMAIN or STORAGE OBTAIN with LOC=(24) to obtain a 24-bit virtual page address, and then using IARVSERV CHANGEACCESS,TARGET_VIEW=HIDDEN to make that page unaddressable. Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CSA 'above the bar'
On Thu, 8 Nov 2007 10:14:42 -, Van Dalsen, Herbie wrote: Apologies, I keep on forgetting that the '8' just signals the above the line, you and Tom and all the others are quite correct with the x'7fff', I have it now... it is a pitty that IBM did not use the lowest bit to signal the line... x'0001' for 24-bit and x'0002' for 32-bit, it would have meant less wastage. Because you would have lost the first few addresses... Tom Marchant said... huh? What wastage are you talking about? I'd suggest that you read chapter 3 of the principles of operation. What do you mean about signaling the line? I think Herbie is just confused. CC -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CSA 'above the bar'
On Thu, 8 Nov 2007 10:14:42 -, Van Dalsen, Herbie wrote: Apologies, I keep on forgetting that the '8' just signals the above the line, you and Tom and all the others are quite correct with the x'7fff', I have it now... it is a pitty that IBM did not use the lowest bit to signal the line... x'0001' for 24-bit and x'0002' for 32-bit, it would have meant less wastage. Because you would have lost the first few addresses... huh? What wastage are you talking about? I'd suggest that you read chapter 3 of the principles of operation. What do you mean about signaling the line? Are you referring to the bit in the PSW that tells the processor whether to operate in 24-bit mode or 31-bit mode? In 24-bit mode, addresses can go from 0 to x'FF'. In 31-bit mode, addresses can go from 0 to x'7FFF'. The line is simply a way of talking about storage locations that cannot be referenced in 24-bit mode In the 360 and 370 architecture (except for the 360-67), addresses were 24 bits, with a maximum possible value of FF. Because of wrap around, the bext byte after x'FF' was location 0. The 370-XA architecture allowed for 31 bit addresses. In 31-bit mode, the next byte after location x'FF' is x'100'. Note that it takes a minimum of 25 bits to represent that address. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CSA 'above the bar'
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Edward Jaffe Sent: Thursday, November 08, 2007 6:27 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: CSA 'above the bar' Thompson, Steve wrote: You did say dedicated. And it certainly appears to me to be both dedicated and reserved (by architectural definition). In the MVS world, if a Problem State program attempts to modify 0xxx (where x is 0-512 decimal and regardless of the content of the current base register) and LAP is on... So it is not truly available (except to the SCP). Otherwise, as I recall [MVS environments], that page is Key0 non-fetch protected. [The above is only for non-Z architected machines. I honestly haven't read the requisite chapters in the new PoOP.] We were talking about a *reserved* virtual address range (aka a hole or dead zone) i.e., one or more pages that are guaranteed to receive a translation exception because the virtual address(es) will never be allocated by the operating system. Page zero does not fit that requirement no matter how hard you squeeze! snip My bad. I missed the hole argument (double entendre intended). It's what I get for skipping through the threads. I see the door over here so I'll just show myself out. Regards, Steve Thompson -- All opinions expressed by me are my own and may not necessarily reflect those of my employer. -- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CSA 'above the bar'
In a message dated 11/8/2007 6:21:04 P.M. Central Standard Time, [EMAIL PROTECTED] writes: In the MVS world, if a Problem State program attempts to modify 0xxx (where x is 0-512 decimal and regardless of the content of the current base register) and LAP is on... So it is not truly available (except to the SCP). I know what you meant, but what you wrote is not technically correct. A problem state program can modify bytes 0-511 of PSA if it alters control register 0 and sets protect key 0 (while in supervisor state), then sets itself to problem state, and then alters that area. Problem state has nothing to do with the various protection mechanisms in the processor architecture when a single instruction's behavior is under consideration. Obviously, if you are in problem state you can't alter CR 0 or set protect key 0, as doing that requires privileged instructions. If you are APF authorized, you can put yourself in supervisor state and then make those changes. But that is a series of instructions, not the one instruction involved in if a Problem State program attempts to modify Also the SCP does not have a monopoly on the STCTL instruction. Any authorized program can do it. The wisdom of and necessity for doing it is another matter. Otherwise, as I recall [MVS environments], that page is Key0 non-fetch protected. Not true any more. The upper half of virtual page 0 (aka PSA) is fetch protected by yet another different, independent protection mechanism. This is so that non-key 0 programs cannot look at the upper half of page 0, in which many register save areas are defined in the z/OS PSA DSECT. There might be clear text, passwords, or who knows what in a register that would be visible to an unauthorized program if such save areas were not fetch-protected somehow. The lower half of page 0 is in key 0 and not fetch protected. Bill Fairchild Franklin, TN ** See what's new at http://www.aol.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CSA 'above the bar'
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Jim Mulder Sent: Thursday, November 08, 2007 4:48 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: CSA 'above the bar' IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU wrote on 11/08/2007 12:24:52 PM: SNIP No, there is no such 24 bit virtual address. With only 4,096 pages that are 24-bit addressable, I guess we didn't want to dedicate one of them for that purpose. SNIP Actually, yes. It is address x'00' and was called PSA (but is actually absolute page 0). And as I recall, it is always reserved when you have more than 1 possible CPU on a machine. Regards, Steve Thompson -- All opinions expressed by me are my own and may not necessarily reflect those of my employer. -- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CSA 'above the bar'
IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU wrote on 11/08/2007 06:23:58 PM: No, there is no such 24 bit virtual address. With only 4,096 pages that are 24-bit addressable, I guess we didn't want to dedicate one of them for that purpose. SNIP Actually, yes. It is address x'00' and was called PSA (but is actually absolute page 0). And as I recall, it is always reserved when you have more than 1 possible CPU on a machine. Actually, no. We are talking about virtual addressability, and x'00' is certainly addressable as a 24-bit virtual address in every address space, and addresses the PSA for the processor on which the code is executing. Furthermore, absolute frame 0 is also addressable by using the SQA virtual address of the PSA for the processor on which the code is executing. This will reverse prefix to absolute 0. As of z/OS 1.5, if there was more than one CPU available at IPL time, the SQA virtual address of the a PSA will be a 31-bit ESQA address. Otherwise, it will be a 24-bit SQA address. As of MVS/XA, we always use a non-zero prefix for each online CPU, so practically speaking, MVS does not use frame absolute 0 for anything other than IPL processing and SADMP processing (SADMP only uses one CPU and uses a prefix of zero). Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CSA 'above the bar'
Thompson, Steve wrote: You did say dedicated. And it certainly appears to me to be both dedicated and reserved (by architectural definition). In the MVS world, if a Problem State program attempts to modify 0xxx (where x is 0-512 decimal and regardless of the content of the current base register) and LAP is on... So it is not truly available (except to the SCP). Otherwise, as I recall [MVS environments], that page is Key0 non-fetch protected. [The above is only for non-Z architected machines. I honestly haven't read the requisite chapters in the new PoOP.] We were talking about a *reserved* virtual address range (aka a hole or dead zone) i.e., one or more pages that are guaranteed to receive a translation exception because the virtual address(es) will never be allocated by the operating system. Page zero does not fit that requirement no matter how hard you squeeze! -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 [EMAIL PROTECTED] http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CSA 'above the bar'
IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU wrote on 11/08/2007 08:21:55 PM: Otherwise, as I recall [MVS environments], that page is Key0 non-fetch protected. Not true any more. The upper half of virtual page 0 (aka PSA) is fetch protected by yet another different, independent protection mechanism. This is so that non-key 0 programs cannot look at the upper half of page 0, in which many register save areas are defined in the z/OS PSA DSECT. There might be clear text, passwords, or who knows what in a register that would be visible to an unauthorized program if such save areas were not fetch-protected somehow. The lower half of page 0 is in key 0 and not fetch protected. Actually, a PSA frame in MVS is key 0 and fetch protected. MVS sets the Fetch-protection-override Control bit in control register 0 to allow the lower half (offset 0:x'7FF') to be fetched by a non-key 0 program. Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CSA 'above the bar'
On Wed, 7 Nov 2007 12:13:24 -0600, Tom Schmidt wrote: On Wed, 7 Nov 2007 11:54:58 -0600, Tom Marchant wrote: The hightest address below the line is x'00FF'. The first address above the line is x'0800'. Check your hex arithmetic: The first address above the line should be x'0100'. Yikes! Thanks for the correction. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CSA 'above the bar'
On Wed, 7 Nov 2007 11:54:58 -0600, Tom Marchant wrote: No. That would be a 28-bit address. A 31-bit address can go up to x'7FFF'. And the line is at 16 MB, determinied by the maximum 24-bit address. The hightest address below the line is x'00FF'. The first address above the line is x'0800'. Check your hex arithmetic: The first address above the line should be x'0100'. -- Tom Schmidt Madison, WI -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CSA 'above the bar'
-Original Message- From: IBM Mainframe Discussion List On Behalf Of Eric Bielefeld - Original Message - From: Chase, John Yep, and in currently practicable terms, we have nearly infinite storage beyond that gap. Isn't that what they said when MVS first came out? And then again when MVS/XA came out? Probably. And I'd imagine a few European kings and queens said something similar when an older CC stumbled onto the Western Hemisphere while trying to sail to India. :-) -jc- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CSA 'above the bar'
The 2G-4G bar dead zone is for catching programs when they convert to AMODE 64. It has nothing to do with programs that run AMODE 24 or AMODE 31. The point is that an existing program that is AMODE 24 or AMODE 31 might have bit 0 of a 4-byte address on and not have any problem (because that bit is ignored when addressing storage). But when it converts to AMODE 64, that bit would now be part of the effective address (which certainly is not what the program wanted). Thus the system is set up so that a reference, in AMODE 64, to that address will program check. Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CSA 'above the bar'
-Original Message- From: IBM Mainframe Discussion List On Behalf Of Eric Bielefeld Isn't it amazing that just a few years ago before the z machines came out, we had 2G to address everything on the machine. Now, we have a hole in the addressing scheme as big as what we used to have for total storage! Yep, and in currently practicable terms, we have nearly infinite storage beyond that gap. -jc- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CSA 'above the bar'
-Original Message- From: IBM Mainframe Discussion List On Behalf Of Van Dalsen, Herbie John, That makes no sense to me... I thought that a 31-bit program could address x'' - 'x'0FFF' below the line, and the same above the line. I.O.W. it could go up to x'8FFF' which means x'0FFF' above ? This means that the hole is from x' 9000' - ? A 31-bit program can address from x'' through x'7FFF'. Expressed in 64-bit addressing, that range is from x'_' through x'_7FFF'. IOW, for a 31-bit program, the high halves of the 64-bit registers do not exist; they may actually contain anything and they will be ignored by 31-bit (and 24-bit) programs. A 64-bit program (amode 64) can address exactly the same range, in the same way, except that the high halves of the 64-bit registers MUST contain all binary zeroes. IN ADDITION, an amode 64 program can address from x'0001_' through x'_'. NO PROGRAM is allowed to address the space from x'_8000' through x'_', which is the bar, the hole, or whatever other name seems appropriate. See previous posts from Ed Jaffe, Peter Relson and Chris Craddock for why that is a good idea. -jc- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CSA 'above the bar'
On Wed, 7 Nov 2007 17:31:31 -, Van Dalsen, Herbie wrote: That makes no sense to me... I thought that a 31-bit program could address x'' - 'x'0FFF' below the line, and the same above the line. I.O.W. it could go up to x'8FFF' which means x'0FFF' above ? This means that the hole is from x' 9000' - ? No. That would be a 28-bit address. A 31-bit address can go up to x'7FFF'. And the line is at 16 MB, determinied by the a 24-bit address. The hightest address below the line is x'00FF'. The first address above the line is x'0800'. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CSA 'above the bar'
Isn't that what they said when MVS first came out? And then again when MVS/XA came out? Eric Bielefeld Sr. z/OS Systems Programmer Milwaukee, Wisconsin 414-475-7434 - Original Message - From: Chase, John [EMAIL PROTECTED] Yep, and in currently practicable terms, we have nearly infinite storage beyond that gap. -jc- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CSA 'above the bar'
Technically, isn't that a 'virtual' hole? Eric Bielefeld wrote: Isn't it amazing that just a few years ago before the z machines came out, we had 2G to address everything on the machine. Now, we have a hole in the addressing scheme as big as what we used to have for total storage! Eric Bielefeld Sr. z/OS Systems Programmer Milwaukee, Wisconsin 414-475-7434 -- Rich Smrcina VM Assist, Inc. Phone: 414-491-6001 Ans Service: 360-715-2467 rich.smrcina at vmassist.com http://www.linkedin.com/in/richsmrcina Catch the WAVV! http://www.wavv.org WAVV 2008 - Chattanooga - April 18-22, 2008 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CSA 'above the bar'
Rick Fochtman wrote: snip-- Correct. For an amode24 program, the entire universe ends at address x'00FF'; the next step wraps back to x''. So for an amode24 program, there is nothing above the line or above the bar because for it, there is neither a line nor a bar. That's also my understanding. So, again, why 24-bit programs could be a reason for 2-4G hole ? -unsnip-- Because bit 0 is the switch between 24-bit mode and 31-bit mode, and as such cannot participate in an address. This is simply not true!! The two AMODE bits (BA EA) are in the PSW, not in address words. And, they don't conflict in any way with the 64-bit Instruction address in the PSW or any of the bits used for addressing in a 64-bit general purpose register. See the PSW format below. And, please read my prior post(s) in this thread for the reason why the purely optional, yet highly valuable, 2G-4G dead zone was implemented for z/OS. +---+ IE Prog E 0R000TOX Key 0MWPA SC C Mask 0 0 0 0 0 0 0A +---+ 0 5 8 12 16 18 20 24 31 +---+ B | A0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0| +---+ 32 63 +---+ Instruction Address +---+ 64 95 +---+ Instruction Address (Continued) +---+ 96127 -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 [EMAIL PROTECTED] http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CSA 'above the bar'
---snip--- The bar is the hole in z/OS between 2G and 4G for all address spaces, as you said. The origin of this thread was the desire for a CSA in the above the bar area, similar to the CSA below the line and the CSA above the line. I termed the phrase GCSA for this area (G for the 64 bit Grande instructions ). ---unsnip- Huh? I was told that The Bar was the top of the 31-bit addressable space. What did I miss? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CSA 'above the bar'
You mean 640K isn't as much as I'll ever need? (No, Bill never really said it) On Wed, 7 Nov 2007 12:38:51 -0600, Eric Bielefeld [EMAIL PROTECTED] wrote: Isn't that what they said when MVS first came out? And then again when MVS/XA came out? Maybe, but this time they really mean it. It is more than we'll ever need (at least in our lifetimes).Even trying ... I can't imagine a number that big. Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:[EMAIL PROTECTED] 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CSA 'above the bar'
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Mark Zelden Sent: Wednesday, November 07, 2007 2:12 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: CSA 'above the bar' You mean 640K isn't as much as I'll ever need? (No, Bill never really said it) Anymore, 640K is not enough to do Hello, World! type programs. Especially when you add in the GUI interface and all the Are You Sure? dialog boxes. Internationalization requires even more memory. -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology The information contained in this e-mail message may be privileged and/or confidential. It is for intended addressee(s) only. If you are not the intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication is strictly prohibited and could, in certain circumstances, be a criminal offense. If you have received this e-mail in error, please notify the sender by reply and delete this message without copying or disclosing it. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CSA 'above the bar'
On Wed, 7 Nov 2007 12:25:45 -0600, Tom Marchant wrote: On Wed, 7 Nov 2007 12:13:24 -0600, Tom Schmidt wrote: On Wed, 7 Nov 2007 11:54:58 -0600, Tom Marchant wrote: The hightest address below the line is x'00FF'. The first address above the line is x'0800'. Check your hex arithmetic: The first address above the line should be x'0100'. Yikes! Thanks for the correction. At first I thought that you were creating a mini-bar... I liked that idea except that it would still be a dry mini-bar. :( -- Tom Schmidt Madison, WI -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CSA 'above the bar'
-Original Message- From: IBM Mainframe Discussion List On Behalf Of McKown, John -Original Message- From: IBM Mainframe Discussion List On Behalf Of Mark Zelden You mean 640K isn't as much as I'll ever need? (No, Bill never really said it) Anymore, 640K is not enough to do Hello, World! type programs. Especially when you add in the GUI interface and all the Are You Sure? dialog boxes. Internationalization requires even more memory. Nowadays, 640K won't even hold the BIOS. -jc- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CSA 'above the bar'
-Original Message- From: IBM Mainframe Discussion List On Behalf Of Rick Fochtman ---snip--- The bar is the hole in z/OS between 2G and 4G for all address spaces, as you said. The origin of this thread was the desire for a CSA in the above the bar area, similar to the CSA below the line and the CSA above the line. I termed the phrase GCSA for this area (G for the 64 bit Grande instructions ). ---unsnip- Huh? I was told that The Bar was the top of the 31-bit addressable space. What did I miss? The bar is actually 2GiB wide, beginning at 64-bit address x'_8000' and ending at 64-bit address x'_'. In the context of this thread, the bar and the hole are one and the same. -jc- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CSA 'above the bar'
snip-- Correct. For an amode24 program, the entire universe ends at address x'00FF'; the next step wraps back to x''. So for an amode24 program, there is nothing above the line or above the bar because for it, there is neither a line nor a bar. That's also my understanding. So, again, why 24-bit programs could be a reason for 2-4G hole ? -unsnip-- Because bit 0 is the switch between 24-bit mode and 31-bit mode, and as such cannot participate in an address. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CSA 'above the bar'
John, That makes no sense to me... I thought that a 31-bit program could address x'' - 'x'0FFF' below the line, and the same above the line. I.O.W. it could go up to x'8FFF' which means x'0FFF' above ? This means that the hole is from x' 9000' - ? Regards Herbie -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Chase, John Sent: 07 November 2007 17:20 To: IBM-MAIN@BAMA.UA.EDU Subject: Re: CSA 'above the bar' -Original Message- From: IBM Mainframe Discussion List On Behalf Of Rick Fochtman ---snip--- The bar is the hole in z/OS between 2G and 4G for all address spaces, as you said. The origin of this thread was the desire for a CSA in the above the bar area, similar to the CSA below the line and the CSA above the line. I termed the phrase GCSA for this area (G for the 64 bit Grande instructions ). ---unsnip- Huh? I was told that The Bar was the top of the 31-bit addressable space. What did I miss? The bar is actually 2GiB wide, beginning at 64-bit address x'_8000' and ending at 64-bit address x'_'. In the context of this thread, the bar and the hole are one and the same. -jc- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html Elavon Financial Services Limited Registered in Ireland: Number 418442 Registered Office: Block E, 1st Floor, Cherrywood Business Park, Loughlinstown, Co. Dublin, Ireland Directors: Robert Abele (USA), John Collins, Terrance Dolan (USA), Pamela Joseph (USA), Declan Lynch, John McNally, Malcolm Towlson Elavon Financial Services Limited, trading as Elavon, is regulated by the Financial Regulator -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CSA 'above the bar'
On Wed, 7 Nov 2007 11:55:35 -0600, Chase, John wrote: NO PROGRAM is allowed to address the space from x'_8000' through x'_' ... More precisely, z/OS will not create a memory object in that range so it will never be allocated storage. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CSA 'above the bar'
In [EMAIL PROTECTED], on 11/05/2007 at 06:11 PM, Dave Kopischke [EMAIL PROTECTED] said: I thought z/VM was the virtualizer ??? (if that's a word). CP is the virtualizer, but z/VM includes other components, e.g., CMS. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CSA 'above the bar'
Ted MacNEIL wrote: Just curious: how S/360 *24-bit* programs could have problems with memory between 2-4G ??? Radaslow, I don't understand your question! 24-bit programmes cannot access virtual above 16Mb. The dead zone is not a problem for real occupancy. Ted, I'm not so slow, call me RadaFAST (or Radoslaw) g I understand, the hole is only in virtual memory, the real memory between 2G and 4G will not be wasted. However I don't understand the reason why any bit in any 24-bit address could mess someting in 64-bit addressing mode. Is it a problem with low-order bit ? -- Radoslaw Skorupka Lodz, Poland -- BRE Bank SA ul. Senatorska 18 00-950 Warszawa www.brebank.pl Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców KRS 025237 NIP: 526-021-50-88 Według stanu na dzień 01.01.2007 r. kapitał zakładowy BRE Banku SA (w całości opłacony) wynosi 118.064.140 zł. W związku z realizacją warunkowego podwyższenia kapitału zakładowego, na podstawie uchwał XVI WZ z dnia 21.05.2003 r., kapitał zakładowy BRE Banku SA może ulec podwyższeniu do kwoty 118.760.528 zł. Akcje w podwyższonym kapitale zakładowym będą w całości opłacone. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CSA 'above the bar'
-Original Message- From: IBM Mainframe Discussion List On Behalf Of Van Dalsen, Herbie [ snip ] With my limited experience I deducted the following: Someone wants to create a shared block of memory CSA/not and share it between programs. My understanding is that a 24-bit program can address 24-bit addresses, 31-bit, 64-bit... So in my inexperienced mind the 24bit program could never share in the happiness of this above the bar heaven of shared storage. Correct. For an amode24 program, the entire universe ends at address x'00FF'; the next step wraps back to x''. So for an amode24 program, there is nothing above the line or above the bar because for it, there is neither a line nor a bar. -jc- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CSA 'above the bar'
Radoslaw, This thread started with the following question: Am I correct in believing that the method to obtain the equivalent of CSA above the bar is to use macro IARV64 with the REQUEST=GETSHARED option? Then one of the other said: Since CSA is available to everyone, how do you make this 'above the 4GB bar' storage available to everyone (read only)? Another said this: If a 24-bit or 31-bit address is interpreted as or expanded to a 64-bit address and the high-order bit happens to be on, that would cast the virtual address into the 2-4 gigabyte range and unpredictable effects could ensue. With my limited experience I deducted the following: Someone wants to create a shared block of memory CSA/not and share it between programs. My understanding is that a 24-bit program can address 24-bit addresses, 31-bit, 64-bit... So in my inexperienced mind the 24bit program could never share in the happiness of this above the bar heaven of shared storage. Regards Herbie -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of R.S. Sent: 06 November 2007 13:13 To: IBM-MAIN@BAMA.UA.EDU Subject: Re: CSA 'above the bar' Ted MacNEIL wrote: Just curious: how S/360 *24-bit* programs could have problems with memory between 2-4G ??? Radaslow, I don't understand your question! 24-bit programmes cannot access virtual above 16Mb. The dead zone is not a problem for real occupancy. Ted, I'm not so slow, call me RadaFAST (or Radoslaw) g I understand, the hole is only in virtual memory, the real memory between 2G and 4G will not be wasted. However I don't understand the reason why any bit in any 24-bit address could mess someting in 64-bit addressing mode. Is it a problem with low-order bit ? -- Radoslaw Skorupka Lodz, Poland -- BRE Bank SA ul. Senatorska 18 00-950 Warszawa www.brebank.pl Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców KRS 025237 NIP: 526-021-50-88 Według stanu na dzień 01.01.2007 r. kapitał zakładowy BRE Banku SA (w całości opłacony) wynosi 118.064.140 zł. W związku z realizacją warunkowego podwyższenia kapitału zakładowego, na podstawie uchwał XVI WZ z dnia 21.05.2003 r., kapitał zakładowy BRE Banku SA może ulec podwyższeniu do kwoty 118.760.528 zł. Akcje w podwyższonym kapitale zakładowym będą w całości opłacone. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html Elavon Financial Services Limited Registered in Ireland: Number 418442 Registered Office: Block E, 1st Floor, Cherrywood Business Park, Loughlinstown, Co. Dublin, Ireland Directors: Robert Abele (USA), John Collins, Terrance Dolan (USA), Pamela Joseph (USA), Declan Lynch, John McNally, Malcolm Towlson Elavon Financial Services Limited, trading as Elavon, is regulated by the Financial Regulator -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CSA 'above the bar'
Chase, John wrote: -Original Message- From: IBM Mainframe Discussion List On Behalf Of Van Dalsen, Herbie [ snip ] With my limited experience I deducted the following: Someone wants to create a shared block of memory CSA/not and share it between programs. My understanding is that a 24-bit program can address 24-bit addresses, 31-bit, 64-bit... So in my inexperienced mind the 24bit program could never share in the happiness of this above the bar heaven of shared storage. Correct. For an amode24 program, the entire universe ends at address x'00FF'; the next step wraps back to x''. So for an amode24 program, there is nothing above the line or above the bar because for it, there is neither a line nor a bar. That's also my understanding. So, again, why 24-bit programs could be a reason for 2-4G hole ? -- Radoslaw Skorupka Lodz, Poland -- BRE Bank SA ul. Senatorska 18 00-950 Warszawa www.brebank.pl Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, nr rejestru przedsibiorców KRS 025237 NIP: 526-021-50-88 Wedug stanu na dzie 01.01.2007 r. kapita zakadowy BRE Banku SA (w caoci opacony) wynosi 118.064.140 z. W zwizku z realizacj warunkowego podwyszenia kapitau zakadowego, na podstawie uchwa XVI WZ z dnia 21.05.2003 r., kapita zakadowy BRE Banku SA moe ulec podwyszeniu do kwoty 118.760.528 z. Akcje w podwyszonym kapitale zakadowym bd w caoci opacone. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CSA 'above the bar'
The following message is a courtesy copy of an article that has been posted to alt.folklore.computers as well. [EMAIL PROTECTED] (Van Dalsen, Herbie) writes: Someone wants to create a shared block of memory CSA/not and share it between programs. My understanding is that a 24-bit program can address 24-bit addresses, 31-bit, 64-bit... So in my inexperienced mind the 24bit program could never share in the happiness of this above the bar heaven of shared storage. as i mentioned in this post http://www.garlic.com/~lynn/2007r.html#62 CSA 'above the bar' ... the way that i originally did sharing implementation and mmap support http://www.garlic.com/~lynn/subtopic.html#mmap was that the same shared object wasn't required to occupy the same virtual address in every virtual address space. however, it could represent a challenge when program images with relocatable address constants were involved http://www.garlic.com/~lynn/subtopic.html#adcon there would still be an issue of the amount of happiness (available in 24bit mode) as opposed to any happiness. it would create a problem for processors that had virtual caches ... i.e. cache lines indexed by virtual address ... resulting in synonyms/duplicates in the cache when the same object was addressed by different virtual addresses. here is old email discussing dual index 3090 D-cache http://www.garlic.com/~lynn/2003j.html#email831118 in this post http://www.garlic.com/~lynn/2003j.html#42 Flash 10208 other posts about virtual cache http://www.garlic.com/~lynn/2006u.html#37 To RISC or not to RISC http://www.garlic.com/~lynn/2006v.html#6 Reasons for the big paradigm switch http://www.garlic.com/~lynn/2006w.html#17 Cache, TLB, and OS one of the other issues for TLB (hardware that translates virtual page addresses to real page addresses) ... all the entries were tagged/associated with specific virtual address spaces ... i.e. STO-associative. This generalized mechanism resulted in a huge number of duplicated entries CSA/common-segment. So as a special case optimization for the whole MVS CSA/common-segment hack gorp ... a special option was provided that identified virtual addresses as something belonging to common-segment. These areas then became associated in the TLB with effectively a system-wide, unique, artificial common-segment virtual address space (effectively violating the whole generalized virtual address space architecture ... rather than associated with generalized virtual address space ... it became associated with a custom operating system specific construct that was known to have very specific characteristics). past post in this thread discussing rise of the whole ugly common segment gorp http://www.garlic.com/~lynn/2007r.html#56 CSA 'above the bar' other posts in this thread http://www.garlic.com/~lynn/2007r.html#64 CSA 'above the bar' http://www.garlic.com/~lynn/2007r.html#65 CSA 'above the bar' -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CSA 'above the bar'
Thanks John -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Chase, John Sent: 06 November 2007 14:40 To: IBM-MAIN@BAMA.UA.EDU Subject: Re: CSA 'above the bar' -Original Message- From: IBM Mainframe Discussion List On Behalf Of Van Dalsen, Herbie [ snip ] With my limited experience I deducted the following: Someone wants to create a shared block of memory CSA/not and share it between programs. My understanding is that a 24-bit program can address 24-bit addresses, 31-bit, 64-bit... So in my inexperienced mind the 24bit program could never share in the happiness of this above the bar heaven of shared storage. Correct. For an amode24 program, the entire universe ends at address x'00FF'; the next step wraps back to x''. So for an amode24 program, there is nothing above the line or above the bar because for it, there is neither a line nor a bar. -jc- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html Elavon Financial Services Limited Registered in Ireland: Number 418442 Registered Office: Block E, 1st Floor, Cherrywood Business Park, Loughlinstown, Co. Dublin, Ireland Directors: Robert Abele (USA), John Collins, Terrance Dolan (USA), Pamela Joseph (USA), Declan Lynch, John McNally, Malcolm Towlson Elavon Financial Services Limited, trading as Elavon, is regulated by the Financial Regulator -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CSA 'above the bar'
Radoslaw, I must have missed the mail you are referring to... Searched my entire mailbox for the word 'hole'... must admit was a bit scared what might turn up, but alas... nothing, if you could please pass me the mail you are referring to, so I can get a better picture, maybe I spoke too quick when I answered your email. Regards Herbie -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of R.S. Sent: 06 November 2007 15:01 To: IBM-MAIN@BAMA.UA.EDU Subject: Re: CSA 'above the bar' Chase, John wrote: -Original Message- From: IBM Mainframe Discussion List On Behalf Of Van Dalsen, Herbie [ snip ] With my limited experience I deducted the following: Someone wants to create a shared block of memory CSA/not and share it between programs. My understanding is that a 24-bit program can address 24-bit addresses, 31-bit, 64-bit... So in my inexperienced mind the 24bit program could never share in the happiness of this above the bar heaven of shared storage. Correct. For an amode24 program, the entire universe ends at address x'00FF'; the next step wraps back to x''. So for an amode24 program, there is nothing above the line or above the bar because for it, there is neither a line nor a bar. That's also my understanding. So, again, why 24-bit programs could be a reason for 2-4G hole ? -- Radoslaw Skorupka Lodz, Poland -- BRE Bank SA ul. Senatorska 18 00-950 Warszawa www.brebank.pl Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, nr rejestru przedsibiorców KRS 025237 NIP: 526-021-50-88 Wedug stanu na dzie 01.01.2007 r. kapita zakadowy BRE Banku SA (w caoci opacony) wynosi 118.064.140 z. W zwizku z realizacj warunkowego podwyszenia kapitau zakadowego, na podstawie uchwa XVI WZ z dnia 21.05.2003 r., kapita zakadowy BRE Banku SA moe ulec podwyszeniu do kwoty 118.760.528 z. Akcje w podwyszonym kapitale zakadowym bd w caoci opacone. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html Elavon Financial Services Limited Registered in Ireland: Number 418442 Registered Office: Block E, 1st Floor, Cherrywood Business Park, Loughlinstown, Co. Dublin, Ireland Directors: Robert Abele (USA), John Collins, Terrance Dolan (USA), Pamela Joseph (USA), Declan Lynch, John McNally, Malcolm Towlson Elavon Financial Services Limited, trading as Elavon, is regulated by the Financial Regulator -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CSA 'above the bar'
It's the peril of upward compatibility. If no one took a 24-bit or 31-bit program and bound it in AMODE 64, there would be no problem. Who's willing to take that bet? Steve R.S. wrote: Correct. For an amode24 program, the entire universe ends at address x'00FF'; the next step wraps back to x''. So for an amode24 program, there is nothing above the line or above the bar because for it, there is neither a line nor a bar. That's also my understanding. So, again, why 24-bit programs could be a reason for 2-4G hole ? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CSA 'above the bar'
Steve, You are probably correct, but as said before... the 24's 31's will not have access to the shared storage, and depending on the % mix of your 31/24/64 bit programs it might defeat the purpose of the exercise to share the storage above the line if you need it below too? Herbie -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Steve Samson Sent: 06 November 2007 16:09 To: IBM-MAIN@BAMA.UA.EDU Subject: Re: CSA 'above the bar' It's the peril of upward compatibility. If no one took a 24-bit or 31-bit program and bound it in AMODE 64, there would be no problem. Who's willing to take that bet? Steve R.S. wrote: Correct. For an amode24 program, the entire universe ends at address x'00FF'; the next step wraps back to x''. So for an amode24 program, there is nothing above the line or above the bar because for it, there is neither a line nor a bar. That's also my understanding. So, again, why 24-bit programs could be a reason for 2-4G hole ? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html Elavon Financial Services Limited Registered in Ireland: Number 418442 Registered Office: Block E, 1st Floor, Cherrywood Business Park, Loughlinstown, Co. Dublin, Ireland Directors: Robert Abele (USA), John Collins, Terrance Dolan (USA), Pamela Joseph (USA), Declan Lynch, John McNally, Malcolm Towlson Elavon Financial Services Limited, trading as Elavon, is regulated by the Financial Regulator -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CSA 'above the bar'
R.S. wrote: I'm not so slow, call me RadaFAST (or Radoslaw) g I understand, the hole is only in virtual memory, the real memory between 2G and 4G will not be wasted. However I don't understand the reason why any bit in any 24-bit address could mess someting in 64-bit addressing mode. Is it a problem with low-order bit ? The consideration of AMODE(24) programs demonstrates quite clearly why the z/OS virtual storage dead zone was purely an option ... never a requirement. In the early 1980s, the 370/XA bi-modal addressing architecture was implemented. There were many, many issues with programs that -- either accidentally or intentionally -- placed garbage in the upper eight bits of an address word. For example, a 24-bit program created an address word containing x'87654321' instead of x'80654321'. A 31-bit program referenced the storage at x'07654321', which was not the intended storage. These issues resulted in all kinds of wrong processing, including storage overlays. It was ugly! And, these bugs were very difficult; nearly impossible to find. Back then, I was an application programmer and had no access to SLIP. I traced through thousands of lines of code using TSO TEST. As I said, Ugly! If you were lucky, and the gods smiled upon you that day, the 31-bit program processing the bad address would suffer an 0C4 abend because the storage (in this case at x'07654321') was not GETMAINed. This was the _best possible_ outcome! It made finding and correcting the problem (relatively) easy! Those experiences were the impetus for the z/OS developers' decision to create a virtual storage dead zone between 2G and 4G. (Fortunately for us, these developers are old enough to actually remember what happened in the early 1980s.) They learned from that experience and did not allow history to repeat itself, They understood that, had they not done so, our programming community (IBM included) would have had to suffer with untold numbers of bugs, similar to what we dealt with (then) 20 years ago with XA, due to 64-bit programs processing 32-bit address words with the high order bit set. In each case, an LLTR or LLTRG is the answer. But, in the absence of a hard failure, recognizing, finding and correcting such bugs would have been extremely difficult. The result of this purely optional, yet extremely wise, design decision, is that a 32-bit address word with the high order bit set -- either accidentally or intentionally -- will cause an 0C4 abend when processed by a 64-bit mode program. No need for luck or a smiling deity,. It is the stated policy of the z/OS operating system that such addresses are guaranteed never to be valid. Hallelujah! -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 [EMAIL PROTECTED] http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CSA 'above the bar'
Ed Jaffe wrote wise words snipped The result of this purely optional, yet extremely wise, design decision, is that a 32-bit address word with the high order bit set -- either accidentally or intentionally -- will cause an 0C4 abend when processed by a 64-bit mode program. No need for luck or a smiling deity,. It is the stated policy of the z/OS operating system that such addresses are guaranteed never to be valid. Hallelujah! I would add what he said :-) but it might help to add a little visual to illustrate the point. As we all know, the high order bit has always been used to signal the last address in a parameter list. This convention was always a bad idea, but arguably it saved a byte or two in antediluvian times. Anyway... if you load that parameter address into a register, the high bit stays on unless you explicitly turn it off and now you have a value that gets passed around (intact) with a garbage bit on and the receiver of that value has no way to know. It just looks like B'1xxx ... ' and in both 24 and 31 bit mode, the hardware conveniently and cheerfully ignores that high order bit - for addressing anyway. Now if you shove that bogus value into the low-order half of a 64-bit register, you get something that looks like this X'', B'1xxx ... ' And if the hardware were to interpret that as an address, it points somewhere into the area greater than or equal to X'_8000' and less than X'0001_' If the operating system allowed any data in that range, then for sure programs that referenced it would break subtly in one way or another. So as Ed said, the designers wisely chose to ensure that ANY address in that range would always be invalid and any attempt to reference anything in that range will get a program check. But don't fall for the sucker bait. X'0001_' and any address higher than that could potentially be valid -EVEN IF- the high order bit is on in the low half. So the so-called dead zone is just that one single contiguous range where the high half of the address is zero and the low half has the high order bit on. The bar is a 2GB-wide hole for z/OS programs. Other z-family operating systems don't need and don't observe this convention. Ah the joys of binary arithmetic :-) CC -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CSA 'above the bar'
-Original Message- From: IBM Mainframe Discussion List On Behalf Of R.S. Chase, John wrote: -Original Message- From: IBM Mainframe Discussion List On Behalf Of Van Dalsen, Herbie [ snip ] With my limited experience I deducted the following: Someone wants to create a shared block of memory CSA/not and share it between programs. My understanding is that a 24-bit program can address 24-bit addresses, 31-bit, 64-bit... So in my inexperienced mind the 24bit program could never share in the happiness of this above the bar heaven of shared storage. Correct. For an amode24 program, the entire universe ends at address x'00FF'; the next step wraps back to x''. So for an amode24 program, there is nothing above the line or above the bar because for it, there is neither a line nor a bar. That's also my understanding. So, again, why 24-bit programs could be a reason for 2-4G hole ? As I recall, it was the use of bit 0 in the address word of the PSW to indicate the amode when XA was introduced that causes the hole between 2 GiB and 4 GiB. -jc- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CSA 'above the bar'
I'm confused. Is the hole between 2GB 4GB for all addresses, or just those in CSA? I thought this thread was only about CSA. Eric Bielefeld Sr. z/OS Systems Programmer Milwaukee, Wisconsin 414-475-7434 - Original Message - From: Craddock, Chris [EMAIL PROTECTED] The result of this purely optional, yet extremely wise, design decision, is that a 32-bit address word with the high order bit set -- either accidentally or intentionally -- will cause an 0C4 abend when processed by a 64-bit mode program. No need for luck or a smiling deity,. It is the stated policy of the z/OS operating system that such addresses are guaranteed never to be valid. Hallelujah! I would add what he said :-) but it might help to add a little visual to illustrate the point. As we all know, the high order bit has always been used to signal the last address in a parameter list. This convention was always a bad idea, but arguably it saved a byte or two in antediluvian times. SNIP CC -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CSA 'above the bar'
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Eric Bielefeld Sent: Tuesday, November 06, 2007 1:25 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: CSA 'above the bar' I'm confused. Is the hole between 2GB 4GB for all addresses, or just those in CSA? I thought this thread was only about CSA. Eric Bielefeld The bar is the hole in z/OS between 2G and 4G for all address spaces, as you said. The origin of this thread was the desire for a CSA in the above the bar area, similar to the CSA below the line and the CSA above the line. I termed the phrase GCSA for this area (G for the 64 bit Grande instructions ). -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology The information contained in this e-mail message may be privileged and/or confidential. It is for intended addressee(s) only. If you are not the intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication is strictly prohibited and could, in certain circumstances, be a criminal offense. If you have received this e-mail in error, please notify the sender by reply and delete this message without copying or disclosing it. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CSA 'above the bar'
In a message dated 11/6/2007 1:24:37 P.M. Central Standard Time, [EMAIL PROTECTED] writes: I'm confused. Is the hole between 2GB 4GB for all addresses, or just those in CSA? All addresses. I thought this thread was only about CSA. Many, if not most, posts' subject eventually strays from the thread's original topic. Bill Fairchild Franklin, TN ** See what's new at http://www.aol.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CSA 'above the bar'
I'm confused. Is the hole between 2GB 4GB for all addresses, or just those in CSA? I thought this thread was only about CSA. It is for all addresses. The CSA angle is misleading. The subject drifted away from the original topic. There isn't any CSA above the bar - at least not yet. There is a form of controlled sharing similar to CSA, but the addressing range for that is currently allocated from the top of the region 3rd table downward. That is waay high, and nowhere near the bar or the hole. CC -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CSA 'above the bar'
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Wayne Driscoll Sent: Sunday, November 04, 2007 7:09 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: CSA 'above the bar' That is why Ed put the word common in quotes. After creating a GETSHARED memory object, every address space that needs access to the object must get the address of the object, and issue IARV64 with the SHAREMEMOBJ option. And by the way, the caller must be sup state or in system key. So no, shared memory objects aren't the equivalent of CSA, since there isn't at IPL time, a block of above the bar, that is always available to every address space. Wayne Driscoll Product Developer Just as a thought. Could somebody write a subsystem which starts at IPL time, does the shared GETMAIN, then (here's the rub) somehow have that memory automatically added to every address space which starts thereafter? I don't know enough about subsystems. I would guess that it would be easier for said subsystem to implement a PC so that a client could request access to the shared GCSA (to coin a phrase for it - G for Grande, like the HLASM instructions). The PC would set up all the difficult parts and return a 64-bit address to the shared memory space. -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology The information contained in this e-mail message may be privileged and/or confidential. It is for intended addressee(s) only. If you are not the intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication is strictly prohibited and could, in certain circumstances, be a criminal offense. If you have received this e-mail in error, please notify the sender by reply and delete this message without copying or disclosing it. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CSA 'above the bar'
The following message is a courtesy copy of an article that has been posted to bit.listserv.ibm-main as well. [EMAIL PROTECTED] (McKown, John) writes: Just as a thought. Could somebody write a subsystem which starts at IPL time, does the shared GETMAIN, then (here's the rub) somehow have that memory automatically added to every address space which starts thereafter? I don't know enough about subsystems. I would guess that it would be easier for said subsystem to implement a PC so that a client could request access to the shared GCSA (to coin a phrase for it - G for Grande, like the HLASM instructions). The PC would set up all the difficult parts and return a 64-bit address to the shared memory space. re: http://www.garlic.com/~lynn/2007r.html#56 CSA 'above the bar' i had done something similar, but different in the waning days of cp67 and then ported it to vm370. it was generalized memmap function that allowed different virtual address spaces to have the same shared memory object at different addresses. vm370 started out with a drastic subset of this function that was cribbed off the virtual IPL command. however, it was dependent on providing r/o sharing of the same object by segment protection feature that was part of the original, base 370 virtual memory architecture. this was one of the features that got dropped when the retrofit of virtual memory hardware to 370/165 ran into scheduling problems ... could regain six month in schedule if several features were dropped (and the favorite son operating system in pok claimed that they didn't find the features really useful). as a result, this caused all the other processors that already had implemented full 370 virtual memory architecture to go back and pull the dropped features. it also forced the vm370 group to significantly redo their implementation on how to protect shared segments across multiple different virtual address spaces (effectively a real cludge that had been used in cp67) in any case, a drastic subset of my (genealized) memory mapping and sharing implementation was eventually released as something called discontiguous shared segments. lots of past posts mentioning the cms filesystem changes supporting memory mapping (and page mapped operation) http://www.garlic.com/~lynn/subtopic.html#mmap and numerous posts discussing the difficulty that the os/360 relocatable adcon convention represented for allowing sharing same object in different virtual address spaces at potentially different virtual addresses http://www.garlic.com/~lynn/subtopic.html#adcon while tss/360 had numerous other problems, they at least adopted a different convention to address relocatable address constant issue for a shared, virtual memory environment -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CSA 'above the bar'
McKown, John wrote: Just as a thought. Could somebody write a subsystem which starts at IPL time, does the shared GETMAIN, then (here's the rub) somehow have that memory automatically added to every address space which starts thereafter? The difficulty of connecting all existing and future address spaces to a 64-bit shared memory object is one reason why many ISVs (and IBM developers) have been lobbying the z/OS developers for true CSA64 support in z/OS. Other reasons include lack of page fix/free and DREF support with existing 64-bit shared memory objects. -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 [EMAIL PROTECTED] http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CSA 'above the bar'
John wrote Could somebody write a subsystem which starts at IPL time, does the shared GETMAIN, then (here's the rub) somehow have that memory automatically added to every address space which starts thereafter? John, What you are looking for sounds very similar to LLA, once you have refreshed LLA after adding/modifying the lnklst... The only difference is that it contains a list of dsn's. Thinking of it... Doesn't CICS attach certain storage automatically to new tasks running in it? Regards Herbie Elavon Financial Services Limited Registered in Ireland: Number 418442 Registered Office: Block E, 1st Floor, Cherrywood Business Park, Loughlinstown, Co. Dublin, Ireland Directors: Robert Abele (USA), John Collins, Terrance Dolan (USA), Pamela Joseph (USA), Declan Lynch, John McNally, Malcolm Towlson Elavon Financial Services Limited, trading as Elavon, is regulated by the Financial Regulator -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CSA 'above the bar'
Part of me quite likes the way that it is done now as it helps prevent someone else overlaying your common area as only address spaces that have registered interest can access the ShrMO. Obviously I can see the benefits of true CSA64 - but I would like the option to making it READONLY to all by default. Rob Scott Rocket Software, Inc 275 Grove Street Newton, MA 02466 617-614-2305 [EMAIL PROTECTED] -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Edward Jaffe Sent: 05 November 2007 14:52 To: IBM-MAIN@BAMA.UA.EDU Subject: Re: CSA 'above the bar' McKown, John wrote: Just as a thought. Could somebody write a subsystem which starts at IPL time, does the shared GETMAIN, then (here's the rub) somehow have that memory automatically added to every address space which starts thereafter? The difficulty of connecting all existing and future address spaces to a 64-bit shared memory object is one reason why many ISVs (and IBM developers) have been lobbying the z/OS developers for true CSA64 support in z/OS. Other reasons include lack of page fix/free and DREF support with existing 64-bit shared memory objects. -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 [EMAIL PROTECTED] http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CSA 'above the bar'
Since z/OS now restricts (by default) CSA storage to be in system key (ie R/O to application code), I would be shocked if they did anything different if above the bar CSA is ever supported. Wayne Driscoll Product Developer JME Software LLC NOTE: All opinions are strictly my own. -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Rob Scott Sent: Monday, November 05, 2007 9:07 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: CSA 'above the bar' Part of me quite likes the way that it is done now as it helps prevent someone else overlaying your common area as only address spaces that have registered interest can access the ShrMO. Obviously I can see the benefits of true CSA64 - but I would like the option to making it READONLY to all by default. Rob Scott Rocket Software, Inc 275 Grove Street Newton, MA 02466 617-614-2305 [EMAIL PROTECTED] -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CSA 'above the bar'
One of the BIG disadvantages of CSA is that too many programs are spending too much time in Key0 and it is all too easy for them to splat all over someone else's product anchor block. I would like to be able to allocate my anchor block in CSA64 and feel safe that only programs with correctly registered interest can alter it (key0 or not). Personally I try leave my code in key0 about as long as I would leave my 4 year old son with a carving knife. Rob Scott Rocket Software, Inc 275 Grove Street Newton, MA 02466 617-614-2305 [EMAIL PROTECTED] -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Wayne Driscoll Sent: 05 November 2007 15:08 To: IBM-MAIN@BAMA.UA.EDU Subject: Re: CSA 'above the bar' Since z/OS now restricts (by default) CSA storage to be in system key (ie R/O to application code), I would be shocked if they did anything different if above the bar CSA is ever supported. Wayne Driscoll Product Developer JME Software LLC NOTE: All opinions are strictly my own. -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Rob Scott Sent: Monday, November 05, 2007 9:07 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: CSA 'above the bar' Part of me quite likes the way that it is done now as it helps prevent someone else overlaying your common area as only address spaces that have registered interest can access the ShrMO. Obviously I can see the benefits of true CSA64 - but I would like the option to making it READONLY to all by default. Rob Scott Rocket Software, Inc 275 Grove Street Newton, MA 02466 617-614-2305 [EMAIL PROTECTED] -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CSA 'above the bar'
Rob Scott wrote: One of the BIG disadvantages of CSA is that too many programs are spending too much time in Key0 and it is all too easy for them to splat all over someone else's product anchor block. I would like to be able to allocate my anchor block in CSA64 and feel safe that only programs with correctly registered interest can alter it (key0 or not). I was contemplating the idea of adding a guard page (via PGSER PROTECT) before and after my most important CSA64 allocations to protect against the most common type of overlays. (No pun intended.) That would make any CSA64 allocation 8K (plus rounding) larger than it has to be -- not something I'd be inclined to do with CSA31 given the existing resource constraint, but in the 64-bit world it might make sense! Personally I try leave my code in key0 about as long as I would leave my 4 year old son with a carving knife. Hear! Hear! I recently went through and replaced a bunch of key0 code with MVCSK instructions. More trouble. But, far less exposure. -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 [EMAIL PROTECTED] http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CSA 'above the bar'
---snip One of the BIG disadvantages of CSA is that too many programs are spending too much time in Key0 and it is all too easy for them to splat all over someone else's product anchor block. I would like to be able to allocate my anchor block in CSA64 and feel safe that only programs with correctly registered interest can alter it (key0 or not). Personally I try leave my code in key0 about as long as I would leave my 4 year old son with a carving knife. unsnip- Or a loaded automatic weapon? :-) I'd much rather see a PC-based mechanism for inter-address-space communications. Storage keys become less important to the caller, and the callee can do validation of addresses, parameters, etc. (I'd also like to see a fast path through SPIE/ESPIE for Monitor Calls, too G) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CSA 'above the bar'
Paul Schuster wrote: Given that this 64-bit storage is allocated in 1MB segments, would not you be adding a guard segment of 1MB each, making your allocation 2MB larger than needed? Thinking out loud. I was also contemplating, in the absence of any such services provided by IBM, putting together my own set of common memory management services that would allow me to sub-allocate the 1MB common memory segments. At this time, I'm taking a wait and see approach watching how IBM system components leverage 64-bit common storage. What works. What doesn't. -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 [EMAIL PROTECTED] http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CSA 'above the bar'
Just curious: how S/360 *24-bit* programs could have problems with memory between 2-4G ??? -- Radoslaw Skorupka Lodz, Poland -- BRE Bank SA ul. Senatorska 18 00-950 Warszawa www.brebank.pl Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, nr rejestru przedsibiorców KRS 025237 NIP: 526-021-50-88 Wedug stanu na dzie 01.01.2007 r. kapita zakadowy BRE Banku SA (w caoci opacony) wynosi 118.064.140 z. W zwizku z realizacj warunkowego podwyszenia kapitau zakadowego, na podstawie uchwa XVI WZ z dnia 21.05.2003 r., kapita zakadowy BRE Banku SA moe ulec podwyszeniu do kwoty 118.760.528 z. Akcje w podwyszonym kapitale zakadowym bd w caoci opacone. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CSA 'above the bar'
On Sun, 4 Nov 2007 18:53:07 + Ted MacNEIL [EMAIL PROTECTED] wrote: :I think the dead zone is necessary in z/VSE for the same reason. :Isn't it also in z/VM? Does z/VM use virtual storage? -- Binyamin Dissen [EMAIL PROTECTED] 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. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CSA 'above the bar'
On Mon, 5 Nov 2007 23:52:45 +, Ted MacNEIL wrote: Does z/VM use virtual storage? Is the bear catholic? Does the Pope ... Yes. It does. I thought z/VM was the virtualizer ??? (if that's a word). As in z/VM allocates real to each of its virtual guests. I'm not a z/VMer (yet), but I have a picture in my mind of z/VM being THE manager of real in that context. Does it use it ??? Yes. Is it presented to z/VM as virtual ??? No. Unless it's a z/VM running under z/VM. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CSA 'above the bar'
[EMAIL PROTECTED] (Binyamin Dissen) writes: Does z/VM use virtual storage? comment in this thread asking how many times has virtual memory been reinvented http://www.garlic.com/~lynn/2007r.html#51 Translation of IBM Basic Assembler to C? some footnotes about the science center http://www.garlic.com/~lynn/subtopic.html#545tech from Melinda's paper VM and the VM Community: Past, Present, and Future http://www.princeton.edu/~melinda ... What was most significant was that the commitment to virtual memory was backed with no successful experience. A system of that period that had implemented virtual memory was the Ferranti Atlas computer, and that was known not to be working well. What was frightening is that nobody who was setting this virtual memory direction at IBM knew why Atlas didn't work ... snip ... quoted from L.W. Comeau, CP-40, the Origin of VM/370, Proceedings of SEAS AM82, September, 1982 and ... Creasy had decided to build CP-40 while riding on the MTA. I launched the effort between Xmas 1964 and year's end, after making the decision while on an MTA bus from Arlington to Cambridge. It was a Tuesday, I believe. (R.J. Creasy, private communication, 1989.) ... snip ... cp40 was built on specially modified 360/40 with virtual memory hardware ... implementing virtual machines. This morphed into cp67 when 360/67 with standard virtual memory became available. and as per previous post in thread http://www.garlic.com/~lynn/2007r.html#56 CSA 'above the bar' http://www.garlic.com/~lynn/2007r.html#62 CSA 'above the bar' the initial hack to mvt for os/vs2, in support of 370 virtual memory, involved borrowing a lot of code from cp67. lots of the vm370 microcode assists developed during the 70s and early 80s eventually morphed into pr/sm and current day LPARs ... which is basically stripped down version of full VM virtual machine function. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CSA 'above the bar'
I thought z/VM was the virtualizer ?? You can have virtual memory in any service machine or CMS environment, as well as other guests. That's why there can be a 'double paging' penalty for a LINUX (or z/OS, or z/VM, or...). z/VM, and its predecessors, has always had the capability to defines more storage than is on the box. It even has swap files. - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CSA 'above the bar'
[EMAIL PROTECTED] (Ted MacNEIL) writes: That's why there can be a 'double paging' penalty for a LINUX (or z/OS, or z/VM, or...). z/VM, and its predecessors, has always had the capability to defines more storage than is on the box. It even has swap files. i had other problems with the os/vs2 group (initially svs before it morphed into mvs). one was all the stuff about LRU replacement algorithms and what it met. lots of posts on the subject http://www.garlic.com/~lynn/subtopic.html#wsclock early on, the pok performance modeling group had discovered on a page fault that if it selected non-changed pages (for replacement) before changed pages ... there wouldn't need the overhead of doing a write before the read. i tried to convince them it would be violated fundamental tenents of LRU replacement paradigm. It wasn't until well into MVS releases that somebody pointed out that they were selecting for replacement, high-use, non-changed, system/shared executable pages, before (lower use) private application data pages (which were changed/modified). another issue isn't just the double paging overhead ... there is the possibility that a virtual guest is running a LRU-like replacement algorithm and selecting a real page with a low use virtual page for replacement (to be refreshed with the missing page). VM may also be doing LRU-like replacement algorithm and noticed (also) that the guest's real page (virtual machine virtual page) hadn't been recently used and selected it for replacement. The pathelogical problem is that the guest may always be deciding it needs one of its real pages (because the corresponding virtual pages weren't being used) moments after VM has decided to remove the corresponding guest virtual machine page from real storage aka running a virtual guest's LRU-like replacement algorithm can violate the premise behind LRU replacement ... since the guest's real page that corresponds to the guest's least recently used virtual page has some probability of being the next page that the guest might actually decide to use misc. past posts in thread: http://www.garlic.com/~lynn/2007r.html#56 CSA 'above the bar' http://www.garlic.com/~lynn/2007r.html#62 CSA 'above the bar' http://www.garlic.com/~lynn/2007r.html#64 CSA 'above the bar' -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CSA 'above the bar'
Radoslaw, A 24-bit program using fullword (24-bit) addresses in a variable length parameter list will have the high-order bit on in the last such address. This bit is ignored in addressing modes less than 64-bit. It is significant in 64-bit mode, placing the address in the dead zone. A hasty conversion to 64-bit mode will expose this problem. It may be that the interrupt handler for references to the dead zone strips the bit and redrives the failing instruction, but I don't know. Those with more specific knowledge are welcome to jump in. Steve R.S. wrote: Just curious: how S/360 *24-bit* programs could have problems with memory between 2-4G ??? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CSA 'above the bar'
Just curious: how S/360 *24-bit* programs could have problems with memory between 2-4G ??? Radaslow, I don't understand your question! 24-bit programmes cannot access virtual above 16Mb. The dead zone is not a problem for real occupancy. - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CSA 'above the bar'
That is why Ed put the word common in quotes. After creating a GETSHARED memory object, every address space that needs access to the object must get the address of the object, and issue IARV64 with the SHAREMEMOBJ option. And by the way, the caller must be sup state or in system key. So no, shared memory objects aren't the equivalent of CSA, since there isn't at IPL time, a block of above the bar, that is always available to every address space. Wayne Driscoll Product Developer JME Software LLC NOTE: All opinions are strictly my own. -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Paul Schuster Sent: Sunday, November 04, 2007 1:54 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: CSA 'above the bar' Ok so how to you 'explicitly' share it? Since CSA is available to everyone, how do you make this 'above the 4GB bar' storage available to everyone (read only)? Thank you. Paul On Fri, 2 Nov 2007 20:32:28 -0700, Edward Jaffe [EMAIL PROTECTED] wrote: Paul Schuster wrote: Am I correct in believing that the method to obtain the equivalent of CSA above the bar is to use macro IARV64 with the REQUEST=GETSHARED option? That's the only common storage currently available above 2G. However, unlike CSA, it must be explicitly shared. -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 [EMAIL PROTECTED] http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CSA 'above the bar'
In a message dated 11/3/2007 9:49:47 A.M. Central Standard Time, [EMAIL PROTECTED] writes: The bar is at 2G. But, there is a dead zone between 2G and 4G that will never be allocated by z/OS. For simplicity, some folks like to think of the z/OS virtual storage bar as being 2G thick. And, of course, there is no equivalent dead zone when working with real storage. And there is not necessarily any equivalent dead zone when working on a z/Architecture mainframe processor with any operating system other than z/OS, and such platforms may even allow virtual addressing in the z/OS-dead zone. Bill Fairchild Franklin, TN ** See what's new at http://www.aol.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CSA 'above the bar'
The discussion suggests that the dead zone represented an arbitrary decision. However it is absolutely necessary to preserve compatibility with programs dating back to OS/360. If a 24-bit or 31-bit address is interpreted as or expanded to a 64-bit address and the high-order bit happens to be on, that would cast the virtual address into the 2-4 gigabyte range and unpredictable effects could ensue. Use of the high-order bit in an address to signal the end of a parameter list is common, and no practical means of filtering or converting the programs is available. I think the dead zone is necessary in z/VSE for the same reason. Other operating systems did not use the high order bit in the same way, so there is no need for the dead zone in virtual addresses. Has this helped to achieve clarity? Steve Samson , IBM Mainframe Discussion List wrote: In a message dated 11/3/2007 9:49:47 A.M. Central Standard Time, [EMAIL PROTECTED] writes: The bar is at 2G. But, there is a dead zone between 2G and 4G that will never be allocated by z/OS. For simplicity, some folks like to think of the z/OS virtual storage bar as being 2G thick. And, of course, there is no equivalent dead zone when working with real storage. And there is not necessarily any equivalent dead zone when working on a z/Architecture mainframe processor with any operating system other than z/OS, and such platforms may even allow virtual addressing in the z/OS-dead zone. Bill Fairchild Franklin, TN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CSA 'above the bar'
Steve Samson wrote: The discussion suggests that the dead zone represented an arbitrary decision. However it is absolutely necessary to preserve compatibility with programs dating back to OS/360. If a 24-bit or 31-bit address is interpreted as or expanded to a 64-bit address and the high-order bit happens to be on, that would cast the virtual address into the 2-4 gigabyte range and unpredictable effects could ensue. Use of the high-order bit in an address to signal the end of a parameter list is common, and no practical means of filtering or converting the programs is available. I think the dead zone is necessary in z/VSE for the same reason. I would not characterize the z/OS (or z/VSE should they ever implement such a thing) virtual storage dead zone as necessary. Rather, it was a convenient and smart choice. Otherwise, many more bugs would have gone undetected. -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 [EMAIL PROTECTED] http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CSA 'above the bar'
I think the dead zone is necessary in z/VSE for the same reason. Isn't it also in z/VM? - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CSA 'above the bar'
Steve Samson [EMAIL PROTECTED] writes: The discussion suggests that the dead zone represented an arbitrary decision. However it is absolutely necessary to preserve compatibility with programs dating back to OS/360. If a 24-bit or 31-bit address is interpreted as or expanded to a 64-bit address and the high-order bit happens to be on, that would cast the virtual address into the 2-4 gigabyte range and unpredictable effects could ensue. Use of the high-order bit in an address to signal the end of a parameter list is common, and no practical means of filtering or converting the programs is available. I think the dead zone is necessary in z/VSE for the same reason. Other operating systems did not use the high order bit in the same way, so there is no need for the dead zone in virtual addresses. Has this helped to achieve clarity? 360/67 had both 24-bit and 32-bit virtual addressing modes ... as well as some other things that didn't reappear until xa. there was some discussion in the xa mode about returning to the 360/67 32-bit mode vis-a-vis using 31-bit ... which would have been in the architecture redbook (the discussion i remember was the difference in operation of things like BXH and BXLE instructions between 31-bit and 32-bit modes) principles of operation was one of the first major publications done with cms script ... in large part because it supported conditional so on the command line ... either the whole architecture redbook could be printed ... or just the principles of operation subset (w/o all the additional detail ... it was called redbook because it was distributed in a 3-ring red binder). common segment area started out being the MVS solution to moving subsystems into the own address space ... and the pervasive use of pointer passing APIs. this was what initially led to MVS kernel image occupying 8mbytes of every 16mbyte virtual address space (so for applications making kernel calls ... the kernel could directly access the parameter list). however, this pointer-passing api paradigm created significant problems when subsystems were moved into their own address space (as part of morphing os/vs2 svs to os/vs2 mvs). common segment could start out as 1mbyte in every address space ... where applications could squirrel away parameter list ... and then make call to the subsystem (passing thru the kernel for the address space switch). the problem was for the larger installations, common segment could grow to 5-6 mbytes that appeared in every application virtual address space (with the 8mbyte taken out for the kernel image) that might leave only 2-3mbytes for applications (out of the 16mbytes). the stop-gap solution in the 3033 time-frame was dual-address space mode (pending access registers, program call, etc) ... there was still a pass thru the kernel to switch to a called subsystem ... but the called subsystem could reach back into the calling application's virtual address space (w/o being forced to resorting to the common segment hack). 3033 also introduced a different above the line concept. the mismatch between processor thruput and disk thruput was becoming more and more exacerbated. i once advocated a statement that over a period of a decade or so, that the disk relative system thruput had declined by an order of magnitude (or more) ... aka disk thruput increased by 3-4 times while processor thruput increased by 40-50 times. As a result, real storage was more and more being used for caching and/or other mechanisms to compensate for the lagging disk relative system thruput. we were starting to see clusters of 4341 decked out w/max. storage and max channel and i/o capacity ... matching or beating 3033 thruput at a lower price. one of the 4341 cluster benefits was that there was more aggregate real storage than the 16mbyte limit for 3033. the hack was to redefine two (undefined/unused) bits in the page table entry. standard page table entry had 16 bits, including a 12bit (4k) page number field (allowed addressing up to 16mbytes real storage). With the two additional bits, it was possible to address up to 16384 4kbyte pages (up to 64mbyte of real storage) ... but only 16mbytes at a time. in real addressing mode ... it was only possible to address the first 16mbytes and in virtual addressing mode ... it was only possible to address a specific 16mbytes (but it was possible to have more than 4096 total 4kbyte pages, some of which could reside about 16mbyte real). it was possible to use channel program IDAL to specify address greater than 16mbyte real address (allowing data to be read/written above the 16mbyte line). however, the actual channel programs were still limited to residing below the 16mbyte line. some of this was masked by the whole channel program translation mechanism that was necessary as part of moving to virtual memory environment. the original transition for mvt was hacking a little bit of support for a single virtual address space (i.e. os/vs2 svs) and
Re: CSA 'above the bar'
On Fri, 2 Nov 2007 20:32:28 -0700, Edward Jaffe [EMAIL PROTECTED] wrote: Paul Schuster wrote: Am I correct in believing that the method to obtain the equivalent of CSA above the bar is to use macro IARV64 with the REQUEST=GETSHARED option? That's the only common storage currently available above 2G. However, unlike CSA, it must be explicitly shared. Above 4 G ? Bruno Bruno(dot)sugliani(at)groupemornay(dot)asso(dot)fr -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CSA 'above the bar'
Anything above 4G IS above 2G. :-) Martin Packer Performance Consultant IBM United Kingdom Ltd +44-20-8832-5167 +44-7802-245-584 [EMAIL PROTECTED] From: Bruno Sugliani [EMAIL PROTECTED] To: IBM-MAIN@BAMA.UA.EDU Date: 03/11/2007 08:39 Subject: Re: CSA 'above the bar' On Fri, 2 Nov 2007 20:32:28 -0700, Edward Jaffe [EMAIL PROTECTED] wrote: Paul Schuster wrote: Am I correct in believing that the method to obtain the equivalent of CSA above the bar is to use macro IARV64 with the REQUEST=GETSHARED option? That's the only common storage currently available above 2G. However, unlike CSA, it must be explicitly shared. Above 4 G ? Bruno Bruno(dot)sugliani(at)groupemornay(dot)asso(dot)fr -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CSA 'above the bar'
So, Ed J says ... That's the only common storage currently available above 2G. However, unlike CSA, it must be explicitly shared. And Bruno tosses some bait with ... Above 4 G ? And Martin bites with ... Anything above 4G IS above 2G. :-) Nobody has said anything wrong as far as I can see, but I reckon the points decision goes to Bruno. Shane ... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CSA 'above the bar'
Bruno Sugliani wrote: On Fri, 2 Nov 2007 20:32:28 -0700, Edward Jaffe [EMAIL PROTECTED] wrote: Paul Schuster wrote: Am I correct in believing that the method to obtain the equivalent of CSA above the bar is to use macro IARV64 with the REQUEST=GETSHARED option? That's the only common storage currently available above 2G. However, unlike CSA, it must be explicitly shared. Above 4 G ? Yes. The bar is at 2G. But, there is a dead zone between 2G and 4G that will never be allocated by z/OS. For simplicity, some folks like to think of the z/OS virtual storage bar as being 2G thick. And, of course, there is no equivalent dead zone when working with real storage. -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 [EMAIL PROTECTED] http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CSA 'above the bar'
Ok so how to you 'explicitly' share it? Since CSA is available to everyone, how do you make this 'above the 4GB bar' storage available to everyone (read only)? Thank you. Paul On Fri, 2 Nov 2007 20:32:28 -0700, Edward Jaffe [EMAIL PROTECTED] wrote: Paul Schuster wrote: Am I correct in believing that the method to obtain the equivalent of CSA above the bar is to use macro IARV64 with the REQUEST=GETSHARED option? That's the only common storage currently available above 2G. However, unlike CSA, it must be explicitly shared. -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 [EMAIL PROTECTED] http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
CSA 'above the bar'
Hello: Am I correct in believing that the method to obtain the equivalent of CSA above the bar is to use macro IARV64 with the REQUEST=GETSHARED option? Thank you. Paul -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: CSA 'above the bar'
Paul Schuster wrote: Am I correct in believing that the method to obtain the equivalent of CSA above the bar is to use macro IARV64 with the REQUEST=GETSHARED option? That's the only common storage currently available above 2G. However, unlike CSA, it must be explicitly shared. -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 [EMAIL PROTECTED] http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
