Why not STORAGE OBTAIN LOC=(31,64)?

2010-12-16 Thread Charles Mills 
What are the reasons, if any, that one would NOT specify 64-bit backing
storage on a STORAGE OBTAIN? Not specify LOC=(whatever,64)?

Are there any circumstances other than a program that explicitly dealt with
real addresses that would make backing storage above the bar likely to be
problematic?

I don't see a clear statement of what the default is if one specifies, for
example, LOC=31. Is that equivalent to LOC=(31,31) or LOC=(31,64)?

Charles

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Why not STORAGE OBTAIN LOC=(31,64)?

2010-12-16 Thread Jim Mulder 
> What are the reasons, if any, that one would NOT specify 64-bit backing
> storage on a STORAGE OBTAIN? Not specify LOC=(whatever,64)?
> 
> Are there any circumstances other than a program that explicitly dealt 
with
> real addresses that would make backing storage above the bar likely to 
be
> problematic?

  No, there are not. 
 
> I don't see a clear statement of what the default is if one specifies, 
for
> example, LOC=31. Is that equivalent to LOC=(31,31) or LOC=(31,64)?

  The book says:

LOC=31 and LOC=(31,31) indicate that virtual and central storage can be 
located anywhere below 2 gigabytes. 

Jim Mulder   z/OS System Test   IBM Corp.  Poughkeepsie,  NY

"I couldn't be clearer if I was a button hook in well water." - Mayor 
Shinn

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Why not STORAGE OBTAIN LOC=(31,64)?

2010-12-16 Thread Charles Mills 
So would a person not be better off -- well, would not the MVS system "be
better off" -- have more options -- by specifying LOC=(31,64)? Why is it not
the default?

Charles
-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf
Of Jim Mulder
Sent: Thursday, December 16, 2010 6:40 PM
To: IBM-MAIN@bama.ua.edu
Subject: Re: Why not STORAGE OBTAIN LOC=(31,64)?

> What are the reasons, if any, that one would NOT specify 64-bit backing
> storage on a STORAGE OBTAIN? Not specify LOC=(whatever,64)?
> 
> Are there any circumstances other than a program that explicitly dealt 
with
> real addresses that would make backing storage above the bar likely to 
be
> problematic?

  No, there are not. 
 
> I don't see a clear statement of what the default is if one specifies, 
for
> example, LOC=31. Is that equivalent to LOC=(31,31) or LOC=(31,64)?

  The book says:

LOC=31 and LOC=(31,31) indicate that virtual and central storage can be 
located anywhere below 2 gigabytes. 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Why not STORAGE OBTAIN LOC=(31,64)?

2010-12-16 Thread Edward Jaffe 

On 12/16/2010 9:34 PM, Charles Mills wrote:

So would a person not be better off -- well, would not the MVS system "be
better off" -- have more options -- by specifying LOC=(31,64)? Why is it not
the default?


LOC=(,64) can't be the default because it would break some existing production 
programs.


--
Edward E Jaffe
Phoenix Software International, Inc
831 Parkview Drive North
El Segundo, CA 90245
310-338-0400 x318
edja...@phoenixsoftware.com
http://www.phoenixsoftware.com/

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Why not STORAGE OBTAIN LOC=(31,64)?

2010-12-17 Thread Mike Schwab 
On Thu, Dec 16, 2010 at 11:47 PM, Edward Jaffe
 wrote:
> On 12/16/2010 9:34 PM, Charles Mills wrote:
>>
>> So would a person not be better off -- well, would not the MVS system "be
>> better off" -- have more options -- by specifying LOC=(31,64)? Why is it
>> not
>> the default?
>
> LOC=(,64) can't be the default because it would break some existing
> production programs.
>
> --
> Edward E Jaffe
> Phoenix Software International, Inc
> 831 Parkview Drive North
> El Segundo, CA 90245
> 310-338-0400 x318
> edja...@phoenixsoftware.com
> http://www.phoenixsoftware.com/
>
http://publib.boulder.ibm.com/infocenter/zos/v1r10/index.jsp?topic=/com.ibm.zos.r10.ieaa600/iea2a68069.htm
-- 
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...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Why not STORAGE OBTAIN LOC=(31,64)?

2010-12-17 Thread Tom Marchant 
On Thu, 16 Dec 2010 21:34:26 -0800, Charles Mills wrote:

>So would a person not be better off -- well, would not the MVS system "be
>better off" -- have more options -- by specifying LOC=(31,64)? Why is it not
>the default?

>From the book:

"When LOC is specified, central storage is allocated anywhere until 
the storage is fixed (for example, using the PGSER macro)."

So the real storage that you request (or default) is not honored, and 
doesn't need to be, unless and until you fix the storage in memory.

-- 
Tom Marchant

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Why not STORAGE OBTAIN LOC=(31,64)?

2010-12-17 Thread Shmuel Metz (Seymour J.) 
In <002701cb9d89$1d4c4850$57e4d8...@org>, on 12/16/2010
   at 05:24 PM, Charles Mills  said:

>Are there any circumstances other than a program that explicitly
>dealt with real addresses that would make backing storage above the
>bar likely to be problematic?

A program that implicitly deals with real addresses, e.g., uses
services that do EXCPVR or STARTIO and use old format CCW's and
IDAL's. What are the BSAM and QSAM requirements on buffer pools these
days?
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Why not STORAGE OBTAIN LOC=(31,64)?

2010-12-17 Thread Edward Jaffe 

On 12/17/2010 2:13 AM, Mike Schwab wrote:

http://publib.boulder.ibm.com/infocenter/zos/v1r10/index.jsp?topic=/com.ibm.zos.r10.ieaa600/iea2a68069.htm


STRAG is a great and useful instruction. But, as a 64-bit analog to LRA I would 
have suggested LRAG.


--
Edward E Jaffe
Phoenix Software International, Inc
831 Parkview Drive North
El Segundo, CA 90245
310-338-0400 x318
edja...@phoenixsoftware.com
http://www.phoenixsoftware.com/

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: Why not STORAGE OBTAIN LOC=(31,64)?

2010-12-18 Thread Peter Relson 
>STRAG is a great and useful instruction. But, as a 64-bit analog to LRA I 
would 
>have suggested LRAG.

Me too. We'll get that fixed.

Peter Relson
z/OS Core Technology Design

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html