Re: IARST64 OWNER SECONDARY ?
On Sun, Nov 24, 2019 at 11:49:33AM -0500, Joe Reichman wrote: > IARST64 OWNER SECONDARY ? > There doesn't seem to be any documentation on what this parm means. Seems > like I would have to do a SSAR to point to the secondary asid and I am > guessing the storage would reside in that asid and reference it with AR > value of 1 ? Well, a quick google: zos iarst64 and the first or 2nd results points to: https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/com.ibm.zos.v2r1.ieaa900/iarst64.htm ,OWNER=HOME ,OWNER=PRIMARY ,OWNER=SECONDARY ,OWNER=SYSTEM ,OWNER=BYASID When COMMON=YES and REQUEST=GET are specified, a required parameter that designates the owner of the storage. ,OWNER=HOME This parameter indicates that the home address space is to be the owner. ,OWNER=PRIMARY This parameter indicates that the primary address space is to be the owner. ,OWNER=SECONDARY This parameter indicates that the secondary address space is to be the owner. ,OWNER=SYSTEM This parameter indicates that the system is to be the owner. Use this only when there is no specific address space which can be considered the owner. ,OWNER=BYASID This parameter indicates that the owner is the ASID specified by the OwningASID parameter. So you're getting some storage and using an interface which doesn't assume your current asid/task is to "own" the storage. What does "own" mean? Likely it means how the system is to track the lifetime of the storage and tie that lifetime to some task or address space's lifetime or reading the description at the top of the page: Note: There is diagnostic support for 64 bit cell pools, created by IARST64, So there is some sort of cell pooling going on. So perhaps the OWNER indicates which cell pool IARST64 should use too. The description also says: Cross memory mode: Any PASN, any HASN, any SASN AMODE: 64-bit ASC mode:Primary or access register (AR) So SSAR doesn't seem to be required at all. I may not have used MVS for a while, but I can still read IBM manuals... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IARST64 OWNER SECONDARY ?
There doesn't seem to be any documentation on what this parm means. Sure there is, as Michael Stein pointed out. And "owner" is the same for getmain, storage obtain, IARV64, IARCP64. Seems like I would have to do a SSAR to point to the secondary asid and I am guessing the storage would reside in that asid and reference it with AR value of 1 ? In all of the obtaining storage cases, owner applies to common storage obtains (as the documentation indicates), and SECONDARY applies to the current secondary ASN when the request is made. Since common storage is never freed by the system upon some work unit's (or address space's) termination, owner does not relate to when the storage might automatically be freed. For these obtaining storage cases, for the most part, owner refers to how the storage is tracked by the system so that in a diagnostic situation you might be able to ascertain who is responsible for obtaining a particular area or who is responsible for using up "so much" common storage. Look up the DIAGxx parmlib member TRAP statement with the CSA and/or SQA options (although that does not apply to the high virtual that IARST64 deals with). Look up IPCS subcommand VERBEXIT VSMDATA OWNCOMM (similarly, I think not for high virtual). The most common usage might be in a space-switch PC target where you want to get common storage that is to be tagged as owned by the PC issuer (which usually is identified by your current secondary ASN). If ever considering SSAR, you need to factor in the authorization requirements, the non-swappability requirements with respect to the target space, and the possibility of needing to use SSAIR instead. 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: IARST64 OWNER SECONDARY ?
Where in 31 bit mode you are able to get 31 bit ( private ) storage in a other address space via the ALET parameter on the STORAGE macro this is not true for 64 bit storage Thanks On Nov 25, 2019, at 8:07 AM, Peter Relson wrote: > > > There doesn't seem to be any documentation on what this parm means. > > Sure there is, as Michael Stein pointed out. And "owner" is the same for > getmain, storage obtain, IARV64, IARCP64. > > Seems like I would have to do a SSAR to point to the secondary asid > and I am > guessing the storage would reside in that asid and reference it with AR > value of 1 ? > > > In all of the obtaining storage cases, owner applies to common storage > obtains (as the documentation indicates), and SECONDARY applies to the > current secondary ASN when the request is made. Since common storage is > never freed by the system upon some work unit's (or address space's) > termination, owner does not relate to when the storage might automatically > be freed. For these obtaining storage cases, for the most part, owner > refers to how the storage is tracked by the system so that in a diagnostic > situation you might be able to ascertain who is responsible for obtaining > a particular area or who is responsible for using up "so much" common > storage. Look up the DIAGxx parmlib member TRAP statement with the CSA > and/or SQA options (although that does not apply to the high virtual that > IARST64 deals with). Look up IPCS subcommand VERBEXIT VSMDATA OWNCOMM > (similarly, I think not for high virtual). > > The most common usage might be in a space-switch PC target where you want > to get common storage that is to be tagged as owned by the PC issuer > (which usually is identified by your current secondary ASN). > > If ever considering SSAR, you need to factor in the authorization > requirements, the non-swappability requirements with respect to the target > space, and the possibility of needing to use SSAIR instead. > > 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IARST64 OWNER SECONDARY ?
On Monday, November 25, 2019, 05:13:35 AM PST, Joseph Reichman wrote: > Where in 31 bit mode you are able to get 31 bit ( private ) storage in a > other address space via the ALET parameter on the STORAGE macro this is not > true for 64 bit storage -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: IARST64 OWNER SECONDARY ?
On Monday, November 25, 2019, 05:13:35 AM PST, Joseph Reichman wrote: > Where in 31 bit mode you are able to get 31 bit ( private ) storage in a > other address space > via the ALET parameter on the STORAGE macro this is > not true for 64 bit storage OWNER= is only valid with COMMON=YES (not private). There does not seem to be an IARST64 parm to specify a foreign address space. IARV64 seems to give you some flexibility by allowing you HOME and PRIMARY which seems suitable for PC routines. You need to explain what you are trying to do. Are you running in a PC routine? Are you trying to share memory with specific address spaces? Jon. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
