Re: Clarification On Storage

[Walt Farrell]

On Sat, 7 Jan 2017 23:19:13 +0200, Binyamin Dissen  
wrote:

>On Sat, 7 Jan 2017 16:57:05 + "Blaicher, Christopher Y."
> wrote:
>
>:>Generally speaking, a page sized request will return a zeroed page, but 
>there is no guarantee for that unless you specify that on the GETMAIN.
>
>What is the case where it would not return a zeroed page?

The case specified by the OP would do it. He hypothesized doing a GETMAIN for 
4096 bytes and getting storage at address 01B00C00. As that is not on a page 
boundary, I think it could only occur if someone had done a GETMAIN for, e.g., 
8192 bytes, gotten the storage from 01B0 through 01B01FFF, then freed 4096 
bytes starting at 01B0C00. Whatever the application left at that address before 
the FREEMAIN would still be there when the GETMAIN returned that same, 
previously used storage.

Nothing guarantees that a 4096-byte request will end up returing storage on a 
page boundary, unless you specify that on the request.

-- 
Walt

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Clarification On Storage

[Blaicher, Christopher Y.]

>From the Assembler Services Reference manual:

Note:
1.When you obtain storage, the system clears the requested storage to zeros if
you obtain either:

8192 bytes or more from a pageable, private storage subpool.

4096 bytes or more from a pageable, private storage subpool, with
BNDRY=PAGE specified.

In all other cases you must not assume that the storage is cleared to zeros.
The caller can specify CHECKZERO=YES to detect these and other cases
where the system clears the requested storage to zeros.

Chris Blaicher
Technical Architect
Mainframe Development
Syncsort Incorporated
2 Blue Hill Plaza #1563, Pearl River, NY 10965

P: 201-930-8234  |  M: 512-627-3803
E: cblaic...@syncsort.com

www.syncsort.com

CONNECTING BIG IRON TO BIG DATA


-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Mike Myers
Sent: Saturday, January 7, 2017 4:36 PM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Clarification On Storage

I don't know when it wouldn't. I personally wrote the code to zero out a page 
on its first reference after GETMAIN back in the '70s. But as has been 
discussed here, if it is part of a page that is FREEMAINed and then the same 
address is returned by a subsequent GETMAIN, data may likely be present from 
its last use. That is unless subsequent versions were modified to clear any 
newly GETMAINed storage.

Mike Myers
Mentor Services Corporation
Technical Team Lead for VSM and RSM development for the first release of MVS

  On 01/07/2017 04:19 PM, Binyamin Dissen wrote:
> On Sat, 7 Jan 2017 16:57:05 + "Blaicher, Christopher Y."
> <cblaic...@syncsort.com> wrote:
>
> :>Generally speaking, a page sized request will return a zeroed page, but 
> there is no guarantee for that unless you specify that on the GETMAIN.
>
> What is the case where it would not return a zeroed page?
>
> --
> Binyamin Dissen <bdis...@dissensoftware.com>
> http://www.dissensoftware.com
>
> Director, Dissen Software, Bar & Grill - Israel
>
>
> Should you use the mailblocks package and expect a response from me,
> you should preauthorize the dissensoftware.com domain.
>
> I very rarely bother responding to challenge/response systems,
> especially those from irresponsible companies.
>
> --
> 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





ATTENTION: -

The information contained in this message (including any files transmitted with 
this message) may contain proprietary, trade secret or other confidential 
and/or legally privileged information. Any pricing information contained in 
this message or in any files transmitted with this message is always 
confidential and cannot be shared with any third parties without prior written 
approval from Syncsort. This message is intended to be read only by the 
individual or entity to whom it is addressed or by their designee. If the 
reader of this message is not the intended recipient, you are on notice that 
any use, disclosure, copying or distribution of this message, in any form, is 
strictly prohibited. If you have received this message in error, please 
immediately notify the sender and/or Syncsort and destroy all copies of this 
message in your possession, custody or control.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Clarification On Storage

[Mike Myers]

I don't know when it wouldn't. I personally wrote the code to zero out a 
page on its first reference after GETMAIN back in the '70s. But as has 
been discussed here, if it is part of a page that is FREEMAINed and then 
the same address is returned by a subsequent GETMAIN, data may likely be 
present from its last use. That is unless subsequent versions were 
modified to clear any newly GETMAINed storage.


Mike Myers
Mentor Services Corporation
Technical Team Lead for VSM and RSM development for the first release of MVS

 On 01/07/2017 04:19 PM, Binyamin Dissen wrote:

On Sat, 7 Jan 2017 16:57:05 + "Blaicher, Christopher Y."
 wrote:

:>Generally speaking, a page sized request will return a zeroed page, but there 
is no guarantee for that unless you specify that on the GETMAIN.

What is the case where it would not return a zeroed page?

--
Binyamin Dissen 
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 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: Clarification On Storage

[Binyamin Dissen]

On Sat, 7 Jan 2017 16:57:05 + "Blaicher, Christopher Y."
 wrote:

:>Generally speaking, a page sized request will return a zeroed page, but there 
is no guarantee for that unless you specify that on the GETMAIN. 

What is the case where it would not return a zeroed page?

--
Binyamin Dissen 
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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Clarification On Storage

[Itschak Mugzach]

The content of the getmained area is much depend on language command and 
options (COBOL initialize foe example).

ITschak

נשלח מה-iPad שלי

‫ב-7 בינו׳ 2017, בשעה 21:57, ‏‏Clark Morris ‏<cfmpub...@ns.sympatico.ca> כתב/ה:‬

> [Default] On 7 Jan 2017 08:56:33 -0800, in bit.listserv.ibm-main
> cblaic...@syncsort.com (Blaicher, Christopher Y.) wrote:
> 
>> Your example of 4K is important because it is a page in size.  A page can 
>> only have one key and can only have one sub-pool associated with it at a 
>> time.
>> 
>> Common memory excepted, once the page is freed, it can be re-assigned into 
>> any key or sub-pool.  Common memory has a whole different set of rules.
>> 
>> Multiple GETMAIN requests for less than a page can be satisfied on one page 
>> as long as they are for the same key and sub-pool.  Once all GETMAINed 
>> memory has been freed on that page, then the page can be re-used.
>> 
>> Generally speaking, a page sized request will return a zeroed page, but 
>> there is no guarantee for that unless you specify that on the GETMAIN.  Any 
>> GETMAIN for less than a page you need to zero the area yourself because 
>> there might be residual data from a previous GETMAIN/FREEMAIN request.  In 
>> any case, it will never be data from another address space as that would 
>> violate security.
> 
> If the "physical" page is not zeroed, what would be there other than
> data left from a previous use.  Actually the same concept would apply
> to all reused storage.
> 
> Clark Morris 
>> 
>> Chris Blaicher
>> Technical Architect
>> Mainframe Development
>> Syncsort Incorporated
>> 2 Blue Hill Plaza #1563, Pearl River, NY 10965
>> 
>> P: 201-930-8234  |  M: 512-627-3803
>> E: cblaic...@syncsort.com
>> 
>> www.syncsort.com
>> 
>> CONNECTING BIG IRON TO BIG DATA
>> 
>> -----Original Message-
>> From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
>> Behalf Of Itschak Mugzach
>> Sent: Saturday, January 7, 2017 11:40 AM
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> Subject: Re: Clarification On Storage
>> 
>> Paul
>> Getmain (in private area as you described) in not a real memory frame (which 
>> is the term for real memory 4k). It get the key based on the subpool you 
>> specify in the macro. So, in short, it is only visible through your asid 
>> page tables.
>> Once your asid ends, so does the page tables. This is why we still use the 
>> term mvs. It is complely virtual.
>> Common area is a bit different as they pre allocated, but this is not what 
>> you was asking.
>> 
>> ITschak
>> 
>> ?? 7  2017 17:10,? "esst...@juno.com" <esst...@juno.com> ???:
>> 
>>> .
>>> I recently read a share presentation on system integrity by Karl Schmitz.
>>> Being a CICS Sysprog I dont get much opportunity to do some of the
>>> topics Karl discussed.
>>> .
>>> .
>>> I do have a question or should I say clarification about STORAGE.
>>> I also looked at the z/OS Authorized Assembler Services guide.
>>> .
>>> Lets say a Non Authorized program runs in Key 8 and issues a
>>> STORAGE/GETMAIN macro for 4096 Byes and the system returns an address
>>> of 01B00C00 (an arbitrary address).
>>> This Non Authorized Program process its data, FREMMAINs the 4096 Bytes
>>> of storage and returns.
>>> ,
>>> .
>>> At some time latter An Authorized Program is started and requests 4096
>>> Bytes of storage in KEY 4. The system returns the same address
>>> 01B00C00 that the Non Authorized Program used.
>>> .
>>> After reviewing Principles of Operation My understanding is that every
>>> page of storage also has a storage kry, which consists of access
>>> control bits, fetch protection bit, reference bit, and a change bit.
>>> .
>>> .
>>> In My scenario I suspect the Operating System changed the storage
>>> access control bits to key 4 to satisfy this request. Assuming the
>>> same address was returned by GETMAIN/STORAGE.
>>> Is My assessment correct ?
>>> .
>>> Im not aware of the operating system pre-allocating Pages of storage
>>> by key ?
>>> Do I understand this correctly ?
>>> .
>>> .
>>> I apologize if this is a novice questions, but Inquiring minds want to
>>> know.
>>> .
>>> .
>>> .
>>> Thanks In Advance
>>> Paul
>>> 
>>> -

Re: Clarification On Storage

[Clark Morris]

[Default] On 7 Jan 2017 08:56:33 -0800, in bit.listserv.ibm-main
cblaic...@syncsort.com (Blaicher, Christopher Y.) wrote:

>Your example of 4K is important because it is a page in size.  A page can only 
>have one key and can only have one sub-pool associated with it at a time.
>
>Common memory excepted, once the page is freed, it can be re-assigned into any 
>key or sub-pool.  Common memory has a whole different set of rules.
>
>Multiple GETMAIN requests for less than a page can be satisfied on one page as 
>long as they are for the same key and sub-pool.  Once all GETMAINed memory has 
>been freed on that page, then the page can be re-used.
>
>Generally speaking, a page sized request will return a zeroed page, but there 
>is no guarantee for that unless you specify that on the GETMAIN.  Any GETMAIN 
>for less than a page you need to zero the area yourself because there might be 
>residual data from a previous GETMAIN/FREEMAIN request.  In any case, it will 
>never be data from another address space as that would violate security.

If the "physical" page is not zeroed, what would be there other than
data left from a previous use.  Actually the same concept would apply
to all reused storage.

Clark Morris 
>
>Chris Blaicher
>Technical Architect
>Mainframe Development
>Syncsort Incorporated
>2 Blue Hill Plaza #1563, Pearl River, NY 10965
>
>P: 201-930-8234  |  M: 512-627-3803
>E: cblaic...@syncsort.com
>
>www.syncsort.com
>
>CONNECTING BIG IRON TO BIG DATA
>
>-Original Message-
>From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On 
>Behalf Of Itschak Mugzach
>Sent: Saturday, January 7, 2017 11:40 AM
>To: IBM-MAIN@LISTSERV.UA.EDU
>Subject: Re: Clarification On Storage
>
>Paul
>Getmain (in private area as you described) in not a real memory frame (which 
>is the term for real memory 4k). It get the key based on the subpool you 
>specify in the macro. So, in short, it is only visible through your asid page 
>tables.
>Once your asid ends, so does the page tables. This is why we still use the 
>term mvs. It is complely virtual.
>Common area is a bit different as they pre allocated, but this is not what you 
>was asking.
>
>ITschak
>
>?? 7  2017 17:10,? "esst...@juno.com" <esst...@juno.com> ???:
>
>> .
>> I recently read a share presentation on system integrity by Karl Schmitz.
>> Being a CICS Sysprog I dont get much opportunity to do some of the
>> topics Karl discussed.
>> .
>> .
>> I do have a question or should I say clarification about STORAGE.
>> I also looked at the z/OS Authorized Assembler Services guide.
>> .
>> Lets say a Non Authorized program runs in Key 8 and issues a
>> STORAGE/GETMAIN macro for 4096 Byes and the system returns an address
>> of 01B00C00 (an arbitrary address).
>> This Non Authorized Program process its data, FREMMAINs the 4096 Bytes
>> of storage and returns.
>> ,
>> .
>> At some time latter An Authorized Program is started and requests 4096
>> Bytes of storage in KEY 4. The system returns the same address
>> 01B00C00 that the Non Authorized Program used.
>> .
>> After reviewing Principles of Operation My understanding is that every
>> page of storage also has a storage kry, which consists of access
>> control bits, fetch protection bit, reference bit, and a change bit.
>> .
>> .
>> In My scenario I suspect the Operating System changed the storage
>> access control bits to key 4 to satisfy this request. Assuming the
>> same address was returned by GETMAIN/STORAGE.
>> Is My assessment correct ?
>> .
>> Im not aware of the operating system pre-allocating Pages of storage
>> by key ?
>> Do I understand this correctly ?
>> .
>> .
>> I apologize if this is a novice questions, but Inquiring minds want to
>> know.
>> .
>> .
>> .
>> Thanks In Advance
>> Paul
>>
>> --
>> 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
>
>
>
>
>
>ATTENTION: -
>
>The information contained in this message (including any files transmitted 
>with this message) may contain proprietary, trade secret or other confidential 
>and/or legally privileged information. Any pricing informa

Re: Clarification On Storage

[Blaicher, Christopher Y.]

Your example of 4K is important because it is a page in size.  A page can only 
have one key and can only have one sub-pool associated with it at a time.

Common memory excepted, once the page is freed, it can be re-assigned into any 
key or sub-pool.  Common memory has a whole different set of rules.

Multiple GETMAIN requests for less than a page can be satisfied on one page as 
long as they are for the same key and sub-pool.  Once all GETMAINed memory has 
been freed on that page, then the page can be re-used.

Generally speaking, a page sized request will return a zeroed page, but there 
is no guarantee for that unless you specify that on the GETMAIN.  Any GETMAIN 
for less than a page you need to zero the area yourself because there might be 
residual data from a previous GETMAIN/FREEMAIN request.  In any case, it will 
never be data from another address space as that would violate security.

Chris Blaicher
Technical Architect
Mainframe Development
Syncsort Incorporated
2 Blue Hill Plaza #1563, Pearl River, NY 10965

P: 201-930-8234  |  M: 512-627-3803
E: cblaic...@syncsort.com

www.syncsort.com

CONNECTING BIG IRON TO BIG DATA

-Original Message-
From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf 
Of Itschak Mugzach
Sent: Saturday, January 7, 2017 11:40 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: Clarification On Storage

Paul
Getmain (in private area as you described) in not a real memory frame (which is 
the term for real memory 4k). It get the key based on the subpool you specify 
in the macro. So, in short, it is only visible through your asid page tables.
Once your asid ends, so does the page tables. This is why we still use the term 
mvs. It is complely virtual.
Common area is a bit different as they pre allocated, but this is not what you 
was asking.

ITschak

בתאריך 7 בינו 2017 17:10,‏ "esst...@juno.com" <esst...@juno.com> כתב:

> .
> I recently read a share presentation on system integrity by Karl Schmitz.
> Being a CICS Sysprog I dont get much opportunity to do some of the
> topics Karl discussed.
> .
> .
> I do have a question or should I say clarification about STORAGE.
> I also looked at the z/OS Authorized Assembler Services guide.
> .
> Lets say a Non Authorized program runs in Key 8 and issues a
> STORAGE/GETMAIN macro for 4096 Byes and the system returns an address
> of 01B00C00 (an arbitrary address).
> This Non Authorized Program process its data, FREMMAINs the 4096 Bytes
> of storage and returns.
> ,
> .
> At some time latter An Authorized Program is started and requests 4096
> Bytes of storage in KEY 4. The system returns the same address
> 01B00C00 that the Non Authorized Program used.
> .
> After reviewing Principles of Operation My understanding is that every
> page of storage also has a storage kry, which consists of access
> control bits, fetch protection bit, reference bit, and a change bit.
> .
> .
> In My scenario I suspect the Operating System changed the storage
> access control bits to key 4 to satisfy this request. Assuming the
> same address was returned by GETMAIN/STORAGE.
> Is My assessment correct ?
> .
> Im not aware of the operating system pre-allocating Pages of storage
> by key ?
> Do I understand this correctly ?
> .
> .
> I apologize if this is a novice questions, but Inquiring minds want to
> know.
> .
> .
> .
> Thanks In Advance
> Paul
>
> --
> 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





ATTENTION: -

The information contained in this message (including any files transmitted with 
this message) may contain proprietary, trade secret or other confidential 
and/or legally privileged information. Any pricing information contained in 
this message or in any files transmitted with this message is always 
confidential and cannot be shared with any third parties without prior written 
approval from Syncsort. This message is intended to be read only by the 
individual or entity to whom it is addressed or by their designee. If the 
reader of this message is not the intended recipient, you are on notice that 
any use, disclosure, copying or distribution of this message, in any form, is 
strictly prohibited. If you have received this message in error, please 
immediately notify the sender and/or Syncsort and destroy all copies of this 
message in your possession, custody or control.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Clarification On Storage

[Joel C. Ewing]

On 01/07/2017 09:07 AM, esst...@juno.com wrote:
> .
> I recently read a share presentation on system integrity by Karl Schmitz.
> Being a CICS Sysprog I dont get much opportunity to do some of the topics 
> Karl discussed.
> .
> .
> I do have a question or should I say clarification about STORAGE.
> I also looked at the z/OS Authorized Assembler Services guide.
> .
> Lets say a Non Authorized program runs in Key 8 and issues a STORAGE/GETMAIN 
> macro
> for 4096 Byes and the system returns an address of 01B00C00 (an arbitrary 
> address).
> This Non Authorized Program process its data, FREMMAINs the 4096 Bytes of 
> storage and returns.
> ,
> .
> At some time latter An Authorized Program is started and requests 4096 Bytes 
> of storage 
> in KEY 4. The system returns the same address 01B00C00 that the Non 
> Authorized Program 
> used.
> .
> After reviewing Principles of Operation
> My understanding is that every page of storage also has a storage kry, which 
> consists of
> access control bits, fetch protection bit, reference bit, and a change bit.  
> .   
> .
> In My scenario I suspect the Operating System changed the storage access 
> control bits
> to key 4 to satisfy this request. Assuming the same address was returned by 
> GETMAIN/STORAGE.
> Is My assessment correct ?
> .
> Im not aware of the operating system pre-allocating Pages of storage by key ?
> Do I understand this correctly ?
> .
> .
> I apologize if this is a novice questions, but Inquiring minds want to know.
> .
> .
> .
> Thanks In Advance
> Paul 
>
Storage requests implicitly or explicitly are from a specific storage
pool based on key requirements and how long the data needs to persist,
and some pools are restricted based on authorization of the requester. 
The rules for allowed storage key values are pool specific.  Released
storage may stay for a while as free storage in that same pool -- don't
remember the exact rules here -- but the association with storage pools
would reduce the likelihood that a subsequent program in that same
address space would later get storage at the same virtual address as was
used fora different storage key.  Also keep in mind we are talking here
about virtual storage, not real storage frames.  My understanding is
that when whole pages of virtual storage are released back to a pool the
association with real page frames and related data is tossed; and when
whole pages are allocated from a storage pool no real storage frames are
actually associated with the pages until first reference to each new
page, at which point it is associated with a zeroed real page.  So even
if unused virtual storage were released from one storage pool and
reassigned to another and a range of virtual address space switched
pools, the new storage pool wouldn't see any data related to the
previous storage pool. And of course with MVS-z/OS the virtual storage
of different address spaces or regions are isolated from each
other(except for the shared "common" area which is controlled by
authorized programs).
Joel C. Ewing

-- 
Joel C. Ewing,Bentonville, AR   jcew...@acm.org 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Clarification On Storage

[Itschak Mugzach]

Paul
Getmain (in private area as you described) in not a real memory frame
(which is the term for real memory 4k). It get the key based on the subpool
you specify in the macro. So, in short, it is only visible through your
asid page tables.
Once your asid ends, so does the page tables. This is why we still use the
term mvs. It is complely virtual.
Common area is a bit different as they pre allocated, but this is not what
you was asking.

ITschak

בתאריך 7 בינו 2017 17:10,‏ "esst...@juno.com"  כתב:

> .
> I recently read a share presentation on system integrity by Karl Schmitz.
> Being a CICS Sysprog I dont get much opportunity to do some of the topics
> Karl discussed.
> .
> .
> I do have a question or should I say clarification about STORAGE.
> I also looked at the z/OS Authorized Assembler Services guide.
> .
> Lets say a Non Authorized program runs in Key 8 and issues a
> STORAGE/GETMAIN macro
> for 4096 Byes and the system returns an address of 01B00C00 (an arbitrary
> address).
> This Non Authorized Program process its data, FREMMAINs the 4096 Bytes of
> storage and returns.
> ,
> .
> At some time latter An Authorized Program is started and requests 4096
> Bytes of storage
> in KEY 4. The system returns the same address 01B00C00 that the Non
> Authorized Program
> used.
> .
> After reviewing Principles of Operation
> My understanding is that every page of storage also has a storage kry,
> which consists of
> access control bits, fetch protection bit, reference bit, and a change bit.
> .
> .
> In My scenario I suspect the Operating System changed the storage access
> control bits
> to key 4 to satisfy this request. Assuming the same address was returned
> by GETMAIN/STORAGE.
> Is My assessment correct ?
> .
> Im not aware of the operating system pre-allocating Pages of storage by
> key ?
> Do I understand this correctly ?
> .
> .
> I apologize if this is a novice questions, but Inquiring minds want to
> know.
> .
> .
> .
> Thanks In Advance
> Paul
>
> --
> 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: Clarification Of STORAGE OBTAIN Parameters

[Peter Relson]

Regarding Common Storage SP253 or SP241

SP253 is not common storage. It is fixed task-owned private (LSQA).

STORAGE OBTAIN,LENGTH=(R0),LOC=31,BNDRY=DBLWD
STORAGE OBTAIN,LENGTH=(R0),LOC=31,BNDRY=DBLWD,SP=0 
What I found puzzling about the query is why the need for 
clarification?.  Is there something that should be clarified in the 
books?
What did the OP find confusing about the default for subpool?

STORAGE OBTAIN,LENGTH=(R0),LOC=31,BNDRY=DBLWD
By the way, it's good style, even if not truly necessary for unauthorized 
programs since they do not have the authority to page-fix storage, to 
identify the allowable real-storage backing for fixed storage by using the 
2-operand form of LOC such as LOC=(31,64).

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: Clarification Of STORAGE OBTAIN Parameters

[Shmuel Metz (Seymour J.)]

In
b6c1eb4364c30e47950e0f68ef65f467cc6f0...@proditmailbox1.us.syncsort.com,
on 03/22/2015
   at 05:43 PM, Blaicher, Christopher Y. cblaic...@syncsort.com
said:

yes

No. Only his first statment is correct.
 
-- 
 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN