Re: Highest address "below the bar"
On 7/2/2016 5:25 PM, Paul Gilmartin wrote: On Sat, 2 Jul 2016 16:06:49 -0700, Ed Jaffe wrote: ... You never get a specification exception on a branch. Specification exception Possible causes are as follows: Branch to an odd-numbered address, caused by an overlaid register save area I was too hasty with my original response. ANY branch to an odd address generates a specification exception. The exception is recognized before exceptions caused by a failure to fetch the storage. Therefore, the result is 0C6 even if the storage does not exist or is fetch protected. Technically, it's not the branch itself abending but I'm not going to dwell on that... -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Highest address "below the bar"
You never get a specification exception ON a branch, but a specification exception may be CAUSED by a branch (per the below ). CharlesSent from a mobile; please excuse the brevity Original message From: Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu> Date: 7/2/16 5:25 PM (GMT-08:00) To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Highest address "below the bar" On Sat, 2 Jul 2016 16:06:49 -0700, Ed Jaffe wrote: > >> ... If an address >>> contains 7BAD then you know it's an intentionally "bad" address. >>> >> Hmmm. If you branch to it, do you get an addressing exception or a >> specification exception. I'd guess the latter, but it might be model >> dependent. > >It's not model dependent. You never get a specification exception on a >branch. > ??? From: CICS Transaction Server CICS Transaction Server 5.2.0 Troubleshooting and support Dealing with the problem Dealing with transaction abend codes What type of program check occurred? ... 6 Specification exception - incorrect format of an instruction or invalid registers. Possible causes are as follows: Overlaid program Incorrect field lengths used in packed decimal multiply and divide instructions Branch to an odd-numbered address, caused by an overlaid register save area -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Highest address "below the bar"
On Sat, 2 Jul 2016 19:25:16 -0500, Paul Gilmartin wrote: >On Sat, 2 Jul 2016 16:06:49 -0700, Ed Jaffe wrote: >> >>> ... If an address contains 7BAD then you know it's an intentionally "bad" address. >>> Hmmm. If you branch to it, do you get an addressing exception or a >>> specification exception. I'd guess the latter, but it might be model >>> dependent. >> >>It's not model dependent. You never get a specification exception on a >>branch. >> >??? From: >CICS Transaction Server >CICS Transaction Server 5.2.0 >Troubleshooting and support >Dealing with the problem >Dealing with transaction abend codes >What type of program check occurred? >... >6 >Specification exception - incorrect format of an instruction or invalid > registers. >Possible causes are as follows: >Overlaid program >Incorrect field lengths used in packed decimal multiply and divide > instructions >Branch to an odd-numbered address, caused by an overlaid register save > area It may be pedantic, but it really isn't an exception generated by the branch itself. The various "branch" instructions generate very few exceptions. If you look at the PoPs you'll typically see them generating only Trace and Transaction Constraint exceptions. From the PoPs, it's true that if you branch to an odd address you'll get a specification exception. However, the exception happens later, after the branch has finished, when the system notices the odd address in the PSW. -- Walt -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Highest address "below the bar"
On Sat, 2 Jul 2016 16:06:49 -0700, Ed Jaffe wrote: > >> ... If an address >>> contains 7BAD then you know it's an intentionally "bad" address. >>> >> Hmmm. If you branch to it, do you get an addressing exception or a >> specification exception. I'd guess the latter, but it might be model >> dependent. > >It's not model dependent. You never get a specification exception on a >branch. > ??? From: CICS Transaction Server CICS Transaction Server 5.2.0 Troubleshooting and support Dealing with the problem Dealing with transaction abend codes What type of program check occurred? ... 6 Specification exception - incorrect format of an instruction or invalid registers. Possible causes are as follows: Overlaid program Incorrect field lengths used in packed decimal multiply and divide instructions Branch to an odd-numbered address, caused by an overlaid register save area -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Highest address "below the bar"
On 7/2/2016 9:56 AM, Paul Gilmartin wrote: On Sat, 2 Jul 2016 08:27:12 -0700, Ed Jaffe wrote: The secondary reason is IEBEYEBALL of dumps, traces, etc. If an address contains 7BAD then you know it's an intentionally "bad" address. Hmmm. If you branch to it, do you get an addressing exception or a specification exception. I'd guess the latter, but it might be model dependent. It's not model dependent. You never get a specification exception on a branch. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Highest address "below the bar"
On 7/2/2016 11:27 AM, Ed Jaffe wrote: On 7/1/2016 10:33 PM, Paul Schuster wrote: Ed: Can you elaborate on the reason(s) for your methodology: "We routinely load base registers and "uninitialized" pointers to 7000 (or sometimes 7BAD) rather than zero." The one reason I can visualize is that instead of unintentionally accessing something in low core you would experience a S0C4 instead. That is the #1 reason! Of course, we now have the ZAD PER interrupt to help catch accidental references to page zero that occur during in-house testing, but that's not nearly as effective as a straight-up 0C4 abend! The secondary reason is IEBEYEBALL of dumps, traces, etc. If an address contains 7BAD then you know it's an intentionally "bad" address. Great, IEBIBALL has been replaced by IEBEYEBALL? No wonder it's not working for me anymore, program object out of a PDSE Regards, Tom Conley -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Highest address "below the bar"
On Sat, 2 Jul 2016 08:27:12 -0700, Ed Jaffe wrote: > >The secondary reason is IEBEYEBALL of dumps, traces, etc. If an address >contains 7BAD then you know it's an intentionally "bad" address. > Hmmm. If you branch to it, do you get an addressing exception or a specification exception. I'd guess the latter, but it might be model dependent. And it might be a good value for NULL if programmers could be relied on to use casting rather than type punning. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Highest address "below the bar"
On 7/1/2016 10:33 PM, Paul Schuster wrote: Ed: Can you elaborate on the reason(s) for your methodology: "We routinely load base registers and "uninitialized" pointers to 7000 (or sometimes 7BAD) rather than zero." The one reason I can visualize is that instead of unintentionally accessing something in low core you would experience a S0C4 instead. That is the #1 reason! Of course, we now have the ZAD PER interrupt to help catch accidental references to page zero that occur during in-house testing, but that's not nearly as effective as a straight-up 0C4 abend! The secondary reason is IEBEYEBALL of dumps, traces, etc. If an address contains 7BAD then you know it's an intentionally "bad" address. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Highest address "below the bar"
Ed: Can you elaborate on the reason(s) for your methodology: "We routinely load base registers and "uninitialized" pointers to 7000 (or sometimes 7BAD) rather than zero." The one reason I can visualize is that instead of unintentionally accessing something in low core you would experience a S0C4 instead. Thank you. Paul -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Highest address "below the bar"
On 6/16/2016 3:57 PM, Jim Mulder wrote: For diagnostic purposes, then 4K page at 7000 is always left invalid in z/OS. And what a valuable design decision that was! We routinely load base registers and "uninitialized" pointers to 7000 (or sometimes 7BAD) rather than zero. Even in 64-bit mode you can leverage _7000, but that's only a 4K page. It could be helpful to have similar treatment for the 2G page at _8000 as well. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: AW: Re: Highest address "below the bar"
I was thinking 64 bit Java uses the addresses from 2G to 3-8G for its storage. That allows it to use a 32 bit pointer that is shifted 3 bits to create the actual address for items, instead of a 64 direct address. On Mon, Jun 20, 2016 at 9:50 AM, Steve Smith wrote: > It's the bar! Only 4KB thick, a big improvement over what I originally > called* the bar from x'8000' through x''. That one however, is > now available for certain uses, although I would avoid it for the same > reasons it was originally black-listed. > > *In no way is this a claim I have naming rights. > > On Fri, Jun 17, 2016 at 12:27 PM, Walt Farrell > wrote: > >> On Fri, 17 Jun 2016 11:21:44 -0400, Jim Mulder wrote: >> >> >> >>For diagnostic purposes, then 4K page at 7000 is always >> >> >>left invalid in z/OS. >> >> > >> >> >That makes the highest numbered, accessible byte to be at address >> >x'7FFFEFFF' >> >> > >> >> That might be due to a requirement of ANSI C that there always be an >> >address >> >> algebraically greater than that of any accessible object, for loop >> >termination >> >> conditions. >> > >> > Not likely. It has been that way since the first release of MVS/XA, >> >circa 1982. That was a time when MVS still ruled with arrogance, and it >> >would takes some doses of marketplace reality changes a few years later >> >before >> >MVS became interested in accommodating C and Unix. >> >> In any case, "ANSI" C didn't exist until (I think) 1989, though the >> standardization effort began in 1983. So the technique is certainly older >> than ANSI C, and not related to it. >> >> -- >> Walt >> >> -- >> For IBM-MAIN subscribe / signoff / archive access instructions, >> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN >> > > > > -- > sas > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Highest address "below the bar
Oops.. forgot about the 32m. Rob Schramm On Mon, Jun 20, 2016, 1:14 PM Tom Marchant < 000a2a8c2020-dmarc-requ...@listserv.ua.edu> wrote: > On Mon, 20 Jun 2016 01:16:42 +, Rob Schramm wrote: > > >Any region size in excess of 16m gives you that amount above the line plus > >everything that is available below the line. REGION=64M is 64M above and > >(assuming you have a 10M below the line YBTLRMV) gives you the 10M below > as > >well. Been that way for as long as I remember. This also assumes there > are > >no exits messing with the REGION. > > Not quite. From the JCL Reference: > > > If your installation does not change the IBM-supplied default limits in > the IEALIMIT > or IEFUSI exit routine modules, then specifying various values for the > region size > has the following results: > > ... > > A value greater than 16,384K or 16M and less than or equal to 32,768K or > 32M -- > gives the job step all the storage available below 16 megabytes. The > resulting size > of the region below 16 megabytes depends on system options and what system > software is installed. The extended region size is the default value of 32 > megabytes. > > A value greater than 32,768K or 32M and less than or equal to 2,096,128K > or 2047M > -- gives the job step all the storage available below 16 megabytes. The > resulting > size of the region below 16 megabytes depends on system options and what > system > software is installed. The extended region size is the specified value. If > the region > size specified is not available above 16 megabytes, the job step receives > whatever > storage is available above 16 megabytes, up to the requested amount, and > the > resulting size of the region above 16 megabytes depends on system options > and > what system software is installed. > > > -- > Tom Marchant > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- Rob Schramm The Art of Mainframe, Inc -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Highest address "below the bar
On Mon, 20 Jun 2016 01:16:42 +, Rob Schramm wrote: >Any region size in excess of 16m gives you that amount above the line plus >everything that is available below the line. REGION=64M is 64M above and >(assuming you have a 10M below the line YBTLRMV) gives you the 10M below as >well. Been that way for as long as I remember. This also assumes there are >no exits messing with the REGION. Not quite. From the JCL Reference: If your installation does not change the IBM-supplied default limits in the IEALIMIT or IEFUSI exit routine modules, then specifying various values for the region size has the following results: ... A value greater than 16,384K or 16M and less than or equal to 32,768K or 32M -- gives the job step all the storage available below 16 megabytes. The resulting size of the region below 16 megabytes depends on system options and what system software is installed. The extended region size is the default value of 32 megabytes. A value greater than 32,768K or 32M and less than or equal to 2,096,128K or 2047M -- gives the job step all the storage available below 16 megabytes. The resulting size of the region below 16 megabytes depends on system options and what system software is installed. The extended region size is the specified value. If the region size specified is not available above 16 megabytes, the job step receives whatever storage is available above 16 megabytes, up to the requested amount, and the resulting size of the region above 16 megabytes depends on system options and what system software is installed. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: AW: Re: Highest address "below the bar"
It's the bar! Only 4KB thick, a big improvement over what I originally called* the bar from x'8000' through x''. That one however, is now available for certain uses, although I would avoid it for the same reasons it was originally black-listed. *In no way is this a claim I have naming rights. On Fri, Jun 17, 2016 at 12:27 PM, Walt Farrell wrote: > On Fri, 17 Jun 2016 11:21:44 -0400, Jim Mulder wrote: > > >> >>For diagnostic purposes, then 4K page at 7000 is always > >> >>left invalid in z/OS. > >> > > >> >That makes the highest numbered, accessible byte to be at address > >x'7FFFEFFF' > >> > > >> That might be due to a requirement of ANSI C that there always be an > >address > >> algebraically greater than that of any accessible object, for loop > >termination > >> conditions. > > > > Not likely. It has been that way since the first release of MVS/XA, > >circa 1982. That was a time when MVS still ruled with arrogance, and it > >would takes some doses of marketplace reality changes a few years later > >before > >MVS became interested in accommodating C and Unix. > > In any case, "ANSI" C didn't exist until (I think) 1989, though the > standardization effort began in 1983. So the technique is certainly older > than ANSI C, and not related to it. > > -- > Walt > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- sas -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Highest address "below the bar
Any region size in excess of 16m gives you that amount above the line plus everything that is available below the line. REGION=64M is 64M above and (assuming you have a 10M below the line YBTLRMV) gives you the 10M below as well. Been that way for as long as I remember. This also assumes there are no exits messing with the REGION. YBTLRMV - Your below the line region may vary Rob Schramm On Sun, Jun 19, 2016, 6:17 PM Paul Gilmartin < 000433f07816-dmarc-requ...@listserv.ua.edu> wrote: > On Sun, 19 Jun 2016 15:32:07 -0400, Peter Relson wrote: > > > >The maximum region size is entertaining, but if you ever granted it, you > >would probably cause the address space to fail. There isn't room for > >x'7FF0' bytes of user storage above the 16M line (and when you specify > >a region size that big, it applies to the area above 16M), > > > Really? I had expected it would apply to both. What happens if a (legacy) > program explicitly requests 24-bit storage? Does that mean that if I > specify REGION=16385K, I can use that amount above the line *plus* > whatever scraps are available below the line? (I understand I'll never > get 16383K.) > > > On Fri, 17 Jun 2016 11:21:44 -0400, Jim Mulder wrote: > > >> >>For diagnostic purposes, then 4K page at 7000 is always > >> >>left invalid in z/OS. > >> > > >> That might be due to a requirement of ANSI C that there always be an > address > >> algebraically greater than that of any accessible object, for loop > >> termination conditions. > > > > Not likely. It has been that way since the first release of MVS/XA, > >circa 1982. That was a time when MVS still ruled with arrogance, and it > >would takes some doses of marketplace reality changes a few years later > >before MVS became interested in accommodating C and Unix. > > > So it's fortuitous that the design meets both requirements. Or, > the designers might have had similar motivaions in both cases. > > -- gil > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- Rob Schramm The Art of Mainframe, Inc -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Highest address "below the bar
On Sun, 19 Jun 2016 15:32:07 -0400, Peter Relson wrote: > >The maximum region size is entertaining, but if you ever granted it, you >would probably cause the address space to fail. There isn't room for >x'7FF0' bytes of user storage above the 16M line (and when you specify >a region size that big, it applies to the area above 16M), > Really? I had expected it would apply to both. What happens if a (legacy) program explicitly requests 24-bit storage? Does that mean that if I specify REGION=16385K, I can use that amount above the line *plus* whatever scraps are available below the line? (I understand I'll never get 16383K.) On Fri, 17 Jun 2016 11:21:44 -0400, Jim Mulder wrote: >> >>For diagnostic purposes, then 4K page at 7000 is always >> >>left invalid in z/OS. >> > >> That might be due to a requirement of ANSI C that there always be an address >> algebraically greater than that of any accessible object, for loop >> termination conditions. > > Not likely. It has been that way since the first release of MVS/XA, >circa 1982. That was a time when MVS still ruled with arrogance, and it >would takes some doses of marketplace reality changes a few years later >before MVS became interested in accommodating C and Unix. > So it's fortuitous that the design meets both requirements. Or, the designers might have had similar motivaions in both cases. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Highest address "below the bar
-- The highest address below the bar is of course 7FFF. -- The highest non-data space address that will not definitely blow up when you reference it is 7FFFEFFF. The high page in 31-bit storage was made non-addressable for RAS/quality reasons (Bob Rogers, I believe, drove it, possibly with the advent of MVS/XA). -- The highest data space address is 7FFF. The maximum region size is entertaining, but if you ever granted it, you would probably cause the address space to fail. There isn't room for x'7FF0' bytes of user storage above the 16M line (and when you specify a region size that big, it applies to the area above 16M), Peter Relson z/OS Core Technology Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: AW: Re: Highest address "below the bar"
On Fri, 17 Jun 2016 11:21:44 -0400, Jim Mulder wrote: >> >>For diagnostic purposes, then 4K page at 7000 is always >> >>left invalid in z/OS. >> > >> >That makes the highest numbered, accessible byte to be at address >x'7FFFEFFF' >> > >> That might be due to a requirement of ANSI C that there always be an >address >> algebraically greater than that of any accessible object, for loop >termination >> conditions. > > Not likely. It has been that way since the first release of MVS/XA, >circa 1982. That was a time when MVS still ruled with arrogance, and it >would takes some doses of marketplace reality changes a few years later >before >MVS became interested in accommodating C and Unix. In any case, "ANSI" C didn't exist until (I think) 1989, though the standardization effort began in 1983. So the technique is certainly older than ANSI C, and not related to it. -- Walt -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: AW: Re: Highest address "below the bar"
> >>For diagnostic purposes, then 4K page at 7000 is always > >>left invalid in z/OS. > > > >That makes the highest numbered, accessible byte to be at address x'7FFFEFFF' > > > That might be due to a requirement of ANSI C that there always be an address > algebraically greater than that of any accessible object, for loop termination > conditions. Not likely. It has been that way since the first release of MVS/XA, circa 1982. That was a time when MVS still ruled with arrogance, and it would takes some doses of marketplace reality changes a few years later before MVS became interested in accommodating C and Unix. Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: AW: Re: Highest address "below the bar"
On Fri, 17 Jun 2016 08:05:55 +0200, Peter Hunkeler wrote: > >>> Is the highest 31-bit address 7FFF or 7FFF? >>> I ask because the largest region size you can request is 2096128K or >>> 2047M, and 2096128 * 1024 = 2,146,435,072 (x7FF0). > > >>For diagnostic purposes, then 4K page at 7000 is always >>left invalid in z/OS. > >That makes the highest numbered, accessible byte to be at address x'7FFFEFFF' > That might be due to a requirement of ANSI C that there always be an address algebraically greater than that of any accessible object, for loop termination conditions. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: Re: Highest address "below the bar"
>> Is the highest 31-bit address 7FFF or 7FFF? >> I ask because the largest region size you can request is 2096128K or >> 2047M, and 2096128 * 1024 = 2,146,435,072 (x7FF0). > >For diagnostic purposes, then 4K page at 7000 is always >left invalid in z/OS. That makes the highest numbered, accessible byte to be at address x'7FFFEFFF' -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Highest address "below the bar"
Thank you! Frank > Date: Thu, 16 Jun 2016 18:57:40 -0400 > From: d10j...@us.ibm.com > Subject: Re: Highest address "below the bar" > To: IBM-MAIN@LISTSERV.UA.EDU > > > Is the highest 31-bit address 7FFF or 7FFF? > > I ask because the largest region size you can request is 2096128K or > > 2047M, and 2096128 * 1024 = 2,146,435,072 (x7FF0). > > For diagnostic purposes, then 4K page at 7000 is always > left invalid in z/OS. > > 2047M is considerably larger than a region size could ever be, since > above and below 16M are separate regions. The maximum region > above 16M is constrained by 2048M - 16M - (ENUC + ELPA + ECSA + ESQA). > > Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Highest address "below the bar"
> Is the highest 31-bit address 7FFF or 7FFF? > I ask because the largest region size you can request is 2096128K or > 2047M, and 2096128 * 1024 = 2,146,435,072 (x7FF0). For diagnostic purposes, then 4K page at 7000 is always left invalid in z/OS. 2047M is considerably larger than a region size could ever be, since above and below 16M are separate regions. The maximum region above 16M is constrained by 2048M - 16M - (ENUC + ELPA + ECSA + ESQA). Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Highest address "below the bar"
Is the highest 31-bit address 7FFF or 7FFF? I ask because the largest region size you can request is 2096128K or 2047M, and 2096128 * 1024 = 2,146,435,072 (x7FF0). Just curious! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
