Re: CSRC4EXP
>I am used the storage macro and the 64 bit version of that is IARST64 That's not how I think of it. Maybe, stretching, you could say that that is so for sizes <= 128K and other limitations. >It works like storage macro accessing an other address space storage in AR mode Unless I am forgetting something, that is not true for IARST64. IARV64 on the other hand does support ALETVALUE. 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: CSRC4EXP
Thanks I think and it is correct the way you ( just an assumption ) designed it That for what I want to do I need IARST64 as opposed to IARV64 I am used the storage macro and the 64 bit version of that is IARST64 It works like storage macro accessing an other address space storage in AR mode If I run out of storage as IARST64 is made For smaller increments I’ll do a get and add another extent That was my mistake Thanks > On Nov 27, 2020, at 8:41 AM, Peter Relson wrote: > > The control structures for the pool are in the space (address space or > data space) identified by the ALET parameter. > The service returns the address of the cell. It is up to you to have set > things up so that use of the provided ALET works in whatever environment > you are calling the service. > > Where the cell resides is up to you. > > Whether you can access it or not is no different than for any other > storage. If the cell "resides in B" then you need addressability to "B". > > 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: CSRC4EXP
The control structures for the pool are in the space (address space or data space) identified by the ALET parameter. The service returns the address of the cell. It is up to you to have set things up so that use of the provided ALET works in whatever environment you are calling the service. Where the cell resides is up to you. Whether you can access it or not is no different than for any other storage. If the cell "resides in B" then you need addressability to "B". 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: CSRC4EXP
Peter I meant IBMMAIN as this isnt assembler an question I didn’t know how to delete the one I posted on the assembler list Serv I read Your share presentation “ Does my address space have enough storage for me “ And The assembler services guide chapter 13 callable cell pool services “ The example there uses IARV64 to get the storage which I couldn’t get working to do what want “ get the cell from a different address space “ And truth is since I need less then 1 Meg IARST64 is better for this purpose Thank you Happy thanksgiving > On Nov 26, 2020, at 10:27 AM, Peter Relson wrote: > > Isn't it considered poor form to post the same thing on multiple > listserv's? > >> there is one alet and pointers to the anchor, extent and cells > No there isn't. There is one ALET (described as the "control ALET") and a > pointer to the anchor and an output pointer to the returned cell. > >> How can it be the anchor extents in address space and the cells in other > Please consider reading your posts before making them (and correcting as > appropriate) so that there are fewer cases of non-English and so that we > don't have to guess what you are asking. The anchor and the extent blocks > are in the same space, therefore one ALET is all that is needed to locate > them. The cell storage area can be anywhere you choose and it is up to > your code to access the cells properly. The CSR pool services do not touch > the cells. They touch only the anchor and the extent blocks. > >> More so can you call CSRC4GET From address space A were the cells reside > in B > If the anchor and extent blocks are in "A" (or any space to which you have > addressability via ALET at the point of the "get") then sure. The system > does not care where the cells are. Now, if you couldn't get a cell and > needed to extend, then you'd be in the position of having to get the cell > storage. For doing that, the normal system rules apply. Pretty much it > comes down to: only if you can access "B" (such as by an ALET). > > 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: CSRC4EXP
Isn't it considered poor form to post the same thing on multiple listserv's? >there is one alet and pointers to the anchor, extent and cells No there isn't. There is one ALET (described as the "control ALET") and a pointer to the anchor and an output pointer to the returned cell. >How can it be the anchor extents in address space and the cells in other Please consider reading your posts before making them (and correcting as appropriate) so that there are fewer cases of non-English and so that we don't have to guess what you are asking. The anchor and the extent blocks are in the same space, therefore one ALET is all that is needed to locate them. The cell storage area can be anywhere you choose and it is up to your code to access the cells properly. The CSR pool services do not touch the cells. They touch only the anchor and the extent blocks. >More so can you call CSRC4GET From address space A were the cells reside in B If the anchor and extent blocks are in "A" (or any space to which you have addressability via ALET at the point of the "get") then sure. The system does not care where the cells are. Now, if you couldn't get a cell and needed to extend, then you'd be in the position of having to get the cell storage. For doing that, the normal system rules apply. Pretty much it comes down to: only if you can access "B" (such as by an ALET). 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
CSRC4EXP
I'm looking at the Parms for this call there is one alet and pointers to the anchor, extent and cells How can it be the anchor extents in address space and the cells in other More so can you call CSRC4GET From address space A were the cells reside in B Thanks -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Cell Pool Services CSRC4EXP
On Mon, 24 Feb 2020 at 08:43, Peter Relson wrote: > The information provided so far does not show doing some sort of "OKSWAP" > afterwards. It would be inappropriate to leave the space non-swappable. Just as it would be inappropriate to make it swappable if it was non-swappable to start with. Issuing DONTSWAP/OKSWAP upon any S0C4 when trying to use AR mode to access another address space doesn't seem sound to me. Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Cell Pool Services CSRC4EXP
I do the okswap after I do a get from the cell pool Thanks > On Feb 24, 2020, at 8:43 AM, Peter Relson wrote: > > I agree with Rob and Binyamin in worrying about a design that imposes > non-swappability on someone else's address space. > I'll point out that in general TRANSWAP involves "swap in" and "don't > allow subsequent swap-out" and "wait for completion by ECB". > You can't do the wait for completion from an SRB. Once you're within an > SRB in the target space (and thus the space is already swapped in) perhaps > DONTSWAP is sufficient. > > The information provided so far does not show doing some sort of "OKSWAP" > afterwards. It would be inappropriate to leave the space non-swappable. > > In general, in the absence of something like TRANSWAP or DONTSWAP, you'd > have to be disabled from the test for swappability through the data > reference or have a suitable local lock in order to prevent swap-out. > > 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: Cell Pool Services CSRC4EXP
I agree with Rob and Binyamin in worrying about a design that imposes non-swappability on someone else's address space. I'll point out that in general TRANSWAP involves "swap in" and "don't allow subsequent swap-out" and "wait for completion by ECB". You can't do the wait for completion from an SRB. Once you're within an SRB in the target space (and thus the space is already swapped in) perhaps DONTSWAP is sufficient. The information provided so far does not show doing some sort of "OKSWAP" afterwards. It would be inappropriate to leave the space non-swappable. In general, in the absence of something like TRANSWAP or DONTSWAP, you'd have to be disabled from the test for swappability through the data reference or have a suitable local lock in order to prevent swap-out. 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: Cell Pool Services CSRC4EXP
If I understand you correctly, this is your design: (1) You grab the ALET for the target address space and then ALESERV with CHKEAX=NO (2) Your code switches to AR mode and attempts to access storage in target address space, most likely while running in key0. (3) If you take an 0c4 abend, you schedule an SRB into the target address space to TRANSWAP and try again from your AR mode code. If so, I would suggest a rethink. Rob Scott Rocket Software From: IBM Mainframe Discussion List on behalf of Joseph Reichman Sent: Sunday, February 23, 2020 3:25:43 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Cell Pool Services CSRC4EXP EXTERNAL EMAIL I accessing the other address space in AR 99 % of the time I won’t have issues from those time that I do and get s0c4 In my recovery I will try to issue an SRB to sysevent swap back in If I’m unsuccessful I’ll bypass the process It’s a much better choice for me than using an SRB > On Feb 23, 2020, at 4:17 PM, Binyamin Dissen > wrote: > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN Rocket Software, Inc. and subsidiaries ¦ 77 Fourth Avenue, Waltham MA 02451 ¦ Main Office Toll Free Number: +1 855.577.4323 Contact Customer Support: https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - http://www.rocketsoftware.com/manage-your-email-preferences Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy This communication and any attachments may contain confidential information of Rocket Software, Inc. All unauthorized use, disclosure or distribution is prohibited. If you are not the intended recipient, please notify Rocket Software immediately and destroy all copies of this communication. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Cell Pool Services CSRC4EXP
I accessing the other address space in AR 99 % of the time I won’t have issues from those time that I do and get s0c4 In my recovery I will try to issue an SRB to sysevent swap back in If I’m unsuccessful I’ll bypass the process It’s a much better choice for me than using an SRB > On Feb 23, 2020, at 4:17 PM, Binyamin Dissen > wrote: > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Cell Pool Services CSRC4EXP
On Sun, 23 Feb 2020 15:44:12 -0500 Joseph Reichman wrote: :>All I can say is you are right these are 1% chance that I can program for I need access to the other address space with little overheard I understand the risk involved :>As long as can address it with a recovery routine its a much better choice than a SRB Why?? As your recovery is to do an SRB anyway. I repeat. Your design is flawed. :>> On Feb 23, 2020, at 2:50 PM, Binyamin Dissen wrote: :>> ?On Sun, 23 Feb 2020 12:16:28 -0500 Joseph Reichman :>> wrote: :>> :>SRB and PC are sometimes not particle :>> Such as? Give a case. :>> :>AR mode has its risk best to have a recovery :>> True for most things. :>> :>Routine to address the rare case and maybe issue a SRB to swap back in Im not at that point yet :>> And when you get back control it may be swapped out again. Your design is :>> flawed. -- 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: Cell Pool Services CSRC4EXP
All I can say is you are right these are 1% chance that I can program for I need access to the other address space with little overheard I understand the risk involved As long as can address it with a recovery routine it’s a much better choice than a SRB > On Feb 23, 2020, at 2:50 PM, Binyamin Dissen > wrote: > > On Sun, 23 Feb 2020 12:16:28 -0500 Joseph Reichman > wrote: > > :>SRB and PC are sometimes not particle > > Such as? Give a case. > > :>AR mode has its risk best to have a recovery > > True for most things. > > :>Routine to address the rare case and maybe issue a SRB to swap back in I’m > not at that point yet > > And when you get back control it may be swapped out again. Your design is > flawed. > > -- > 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: Cell Pool Services CSRC4EXP
Joesph, As a suggestion from an older T-rex , it would help greatly if you elaborated on what your trying to accomplish with address spaces and dataspaces. Sharing knowledge and asking questions is always helpful for all. Regards, Scott z/OS Lead IDMWORKS On Sun, Feb 23, 2020 at 2:55 PM Joseph Reichman wrote: > Thanks > > > On Feb 23, 2020, at 2:47 PM, Rob Scott wrote: > > > > My session is on Wednesday Feb 26th at 4.45pm > > > > After the session is complete, I will be making the GitHub repo > containing the source public. > > > > The focus of the presentation is not so much the end result but the > techniques employed behind the scenes. > > > > Hopefully it will provide a decent starter example of how to do this > sort of thing with secure engineering protocols in mind. > > > > Rob Scott > > Rocket Software > > > > On 23 Feb 2020 1:02 pm, Joseph Reichman wrote: > > EXTERNAL EMAIL > > > > > > > > > > > > Rob > > > > With all due respect to you as I have seen post about your XMEM share > session I understand the caveat of AR programming as it relates to address > spaces > > > > However nothing is 100 % generally SRB is the choice to do XMEM as it > avoids these problems > > > > > > Can I ask where and when is your XMEM session in share I would like to > see if I can attend > > > > thanks > > > > -Original Message- > > From: IBM Mainframe Discussion List On > Behalf Of Rob Scott > > Sent: Sunday, February 23, 2020 1:34 PM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: Cell Pool Services CSRC4EXP > > > > Personally I think that if your design requires you to alter the > attributes of an address space which is not under your control, then it is > likely that the design is flawed. > > > > Firing SRBs into random address spaces and issuing TRANSWAP just to > perform some sort of memory management does not "smell right" to me. > > > > Rob Scott > > Rocket Software > > > > -Original Message- > > From: IBM Mainframe Discussion List On > Behalf Of Joseph Reichman > > Sent: Sunday, February 23, 2020 3:43 PM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: Cell Pool Services CSRC4EXP > > > > EXTERNAL EMAIL > > > > > > > > > > > > Then me just say what I do in the SRB > > > > The following > > > >XR R1,R1 Clear R1 as we cann't wait in > > SRB mode > > SYSEVENT TRANSWAP,ENTRY=BRANCH,ASID=(R4) > > > > > > Before I issue a get (actually access the cell) in a other > address space double check we are okay > > > > L R1,ASCBOUCB-ASCB(R1) > > USING OUCB,R1 > > TMOUCBSFL,OUCBNSWis address space swapped in > > > > BZNOTSWAPno; > > > > > > -Original Message- > > From: IBM Mainframe Discussion List On > Behalf Of Peter Relson > > Sent: Sunday, February 23, 2020 9:51 AM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: Cell Pool Services CSRC4EXP > > > > > > Should just say data space > > > > > > Your logic confounds me. It can certainly be an address space. Whether > it is an address space or data space, you have to do things right. > > > > > > page 217 ( chapter 13) of the assembler services guide Page and > chapter references don't work too well if someone is looking at knowledge > center. Let alone a reference without indicating the release. > > But I assume that you are referring to Figure 1 within Callable cell > pool services -> Storage considerations. > > > > 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 > Rocket Software, Inc. and subsidiaries ■ > 77 Fourth Avenue, Waltham MA 02451 ■ Main Office Toll Free Number: +1 > 855.577.4323 Contact Customer Support: > https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmy.rocketsoftware.com%2FRocketCommunity%2FRCEmailSupportdata=02%7C01%7C%7Cadbfe8fa1ace4c10894
Re: Cell Pool Services CSRC4EXP
Thanks On Feb 23, 2020, at 2:47 PM, Rob Scott wrote: > > My session is on Wednesday Feb 26th at 4.45pm > > After the session is complete, I will be making the GitHub repo containing > the source public. > > The focus of the presentation is not so much the end result but the > techniques employed behind the scenes. > > Hopefully it will provide a decent starter example of how to do this sort of > thing with secure engineering protocols in mind. > > Rob Scott > Rocket Software > > On 23 Feb 2020 1:02 pm, Joseph Reichman wrote: > EXTERNAL EMAIL > > > > > > Rob > > With all due respect to you as I have seen post about your XMEM share session > I understand the caveat of AR programming as it relates to address spaces > > However nothing is 100 % generally SRB is the choice to do XMEM as it avoids > these problems > > > Can I ask where and when is your XMEM session in share I would like to see if > I can attend > > thanks > > -Original Message- > From: IBM Mainframe Discussion List On Behalf Of > Rob Scott > Sent: Sunday, February 23, 2020 1:34 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Cell Pool Services CSRC4EXP > > Personally I think that if your design requires you to alter the attributes > of an address space which is not under your control, then it is likely that > the design is flawed. > > Firing SRBs into random address spaces and issuing TRANSWAP just to perform > some sort of memory management does not "smell right" to me. > > Rob Scott > Rocket Software > > -Original Message- > From: IBM Mainframe Discussion List On Behalf Of > Joseph Reichman > Sent: Sunday, February 23, 2020 3:43 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Cell Pool Services CSRC4EXP > > EXTERNAL EMAIL > > > > > > Then me just say what I do in the SRB > > The following > >XR R1,R1 Clear R1 as we cann't wait in > SRB mode > SYSEVENT TRANSWAP,ENTRY=BRANCH,ASID=(R4) > > > Before I issue a get (actually access the cell) in a other address > space double check we are okay > > L R1,ASCBOUCB-ASCB(R1) > USING OUCB,R1 > TMOUCBSFL,OUCBNSWis address space swapped in > > BZNOTSWAPno; > > > -Original Message- > From: IBM Mainframe Discussion List On Behalf Of > Peter Relson > Sent: Sunday, February 23, 2020 9:51 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Cell Pool Services CSRC4EXP > > > Should just say data space > > > Your logic confounds me. It can certainly be an address space. Whether it is > an address space or data space, you have to do things right. > > > page 217 ( chapter 13) of the assembler services guide Page and > chapter references don't work too well if someone is looking at knowledge > center. Let alone a reference without indicating the release. > But I assume that you are referring to Figure 1 within Callable cell pool > services -> Storage considerations. > > 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 > Rocket Software, Inc. and subsidiaries ■ 77 > Fourth Avenue, Waltham MA 02451 ■ Main Office Toll Free Number: +1 > 855.577.4323 Contact Customer Support: > https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmy.rocketsoftware.com%2FRocketCommunity%2FRCEmailSupportdata=02%7C01%7C%7Cadbfe8fa1ace4c10894308d7b892f485%7C79544c1eed224879a082b67a9a672aae%7C0%7C0%7C637180813657898313sdata=9Eu%2BMVdjXRKnWCda95yEEEApnMmbJnF4mJkn3XHOzVo%3Dreserved=0 > Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - > https://nam01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.rocketsoftware.com%2Fmanage-your-email-preferencesdata=02%7C01%7C%7Cadbfe8fa1ace4c10894308d7b892f485%7C79544c1eed224879a082b67a9a672aae%7C0%7C0%7C637180813657898313sdata=yB%2FgsAe3cncDA8mpa4nwZS2wAjJOfHDMugpteABe%2BSA%3Dreserved=0 > Privacy Policy - > https://nam01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.rocketsoftware.com%2Fcompany%2Flegal%2Fprivacy-policydata=02%7C01%7C%7Cadbfe8fa1ace4c10894308d7b892f485%7C79544c1eed224879a082b67a9a672aae
Re: Cell Pool Services CSRC4EXP
On Sun, 23 Feb 2020 12:16:28 -0500 Joseph Reichman wrote: :>SRB and PC are sometimes not particle Such as? Give a case. :>AR mode has its risk best to have a recovery True for most things. :>Routine to address the rare case and maybe issue a SRB to swap back in Im not at that point yet And when you get back control it may be swapped out again. Your design is flawed. -- 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: Cell Pool Services CSRC4EXP
On Sun, 23 Feb 2020 08:33:40 -0800 Charles Mills wrote: :>There is at least a "technical" risk that the status of the address space :>could change to swappable between your TM and whatever action you do based :>on the determination of non-swappability, but for personal use software I :>suppose you might find that risk acceptable. Or you can take the hit and allow your recovery routine to take alternative action. :>Does non-swappable guarantee "swapped in"? That's a serious question. I :>don't know the answer. I could not imagine otherwise. :> Can an already swapped-out address space be marked :>non-swappable? Again, probably a manageable risk for personal use software. Ditto. But it is possible for an address space to be temporarily non-swapable such as during I/O. :>Charles :> :> :>-Original Message- :>From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On :>Behalf Of Joseph Reichman :>Sent: Sunday, February 23, 2020 7:43 AM :>To: IBM-MAIN@LISTSERV.UA.EDU :>Subject: Re: Cell Pool Services CSRC4EXP :> :>Then me just say what I do in the SRB :> :>The following :> :>XR R1,R1 Clear R1 as we cann't wait in :>SRB mode :> SYSEVENT TRANSWAP,ENTRY=BRANCH,ASID=(R4) :> :> :> Before I issue a get (actually access the cell) in a other :>address space double check we are okay :> :> L R1,ASCBOUCB-ASCB(R1) :> USING OUCB,R1 :> TMOUCBSFL,OUCBNSWis address space swapped in :> :> BZNOTSWAPno; :> :> :>-Original Message- :>From: IBM Mainframe Discussion List On Behalf Of :>Peter Relson :>Sent: Sunday, February 23, 2020 9:51 AM :>To: IBM-MAIN@LISTSERV.UA.EDU :>Subject: Re: Cell Pool Services CSRC4EXP :> :> :>Should just say data space :> :> :>Your logic confounds me. It can certainly be an address space. Whether it is :>an address space or data space, you have to do things right. :> :> :>page 217 ( chapter 13) of the assembler services guide Page and :>chapter references don't work too well if someone is looking at knowledge :>center. Let alone a reference without indicating the release. :>But I assume that you are referring to Figure 1 within Callable cell pool :>services -> Storage considerations. :> :>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 :> :>-- :>For IBM-MAIN subscribe / signoff / archive access instructions, :>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- 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: Cell Pool Services CSRC4EXP
My session is on Wednesday Feb 26th at 4.45pm After the session is complete, I will be making the GitHub repo containing the source public. The focus of the presentation is not so much the end result but the techniques employed behind the scenes. Hopefully it will provide a decent starter example of how to do this sort of thing with secure engineering protocols in mind. Rob Scott Rocket Software On 23 Feb 2020 1:02 pm, Joseph Reichman wrote: EXTERNAL EMAIL Rob With all due respect to you as I have seen post about your XMEM share session I understand the caveat of AR programming as it relates to address spaces However nothing is 100 % generally SRB is the choice to do XMEM as it avoids these problems Can I ask where and when is your XMEM session in share I would like to see if I can attend thanks -Original Message- From: IBM Mainframe Discussion List On Behalf Of Rob Scott Sent: Sunday, February 23, 2020 1:34 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Cell Pool Services CSRC4EXP Personally I think that if your design requires you to alter the attributes of an address space which is not under your control, then it is likely that the design is flawed. Firing SRBs into random address spaces and issuing TRANSWAP just to perform some sort of memory management does not "smell right" to me. Rob Scott Rocket Software -Original Message- From: IBM Mainframe Discussion List On Behalf Of Joseph Reichman Sent: Sunday, February 23, 2020 3:43 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Cell Pool Services CSRC4EXP EXTERNAL EMAIL Then me just say what I do in the SRB The following XR R1,R1 Clear R1 as we cann't wait in SRB mode SYSEVENT TRANSWAP,ENTRY=BRANCH,ASID=(R4) Before I issue a get (actually access the cell) in a other address space double check we are okay L R1,ASCBOUCB-ASCB(R1) USING OUCB,R1 TMOUCBSFL,OUCBNSWis address space swapped in BZNOTSWAPno; -Original Message- From: IBM Mainframe Discussion List On Behalf Of Peter Relson Sent: Sunday, February 23, 2020 9:51 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Cell Pool Services CSRC4EXP Should just say data space Your logic confounds me. It can certainly be an address space. Whether it is an address space or data space, you have to do things right. page 217 ( chapter 13) of the assembler services guide Page and chapter references don't work too well if someone is looking at knowledge center. Let alone a reference without indicating the release. But I assume that you are referring to Figure 1 within Callable cell pool services -> Storage considerations. 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 Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA 02451 ■ Main Office Toll Free Number: +1 855.577.4323 Contact Customer Support: https://nam01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmy.rocketsoftware.com%2FRocketCommunity%2FRCEmailSupportdata=02%7C01%7C%7Cadbfe8fa1ace4c10894308d7b892f485%7C79544c1eed224879a082b67a9a672aae%7C0%7C0%7C637180813657898313sdata=9Eu%2BMVdjXRKnWCda95yEEEApnMmbJnF4mJkn3XHOzVo%3Dreserved=0 Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - https://nam01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.rocketsoftware.com%2Fmanage-your-email-preferencesdata=02%7C01%7C%7Cadbfe8fa1ace4c10894308d7b892f485%7C79544c1eed224879a082b67a9a672aae%7C0%7C0%7C637180813657898313sdata=yB%2FgsAe3cncDA8mpa4nwZS2wAjJOfHDMugpteABe%2BSA%3Dreserved=0 Privacy Policy - https://nam01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.rocketsoftware.com%2Fcompany%2Flegal%2Fprivacy-policydata=02%7C01%7C%7Cadbfe8fa1ace4c10894308d7b892f485%7C79544c1eed224879a082b67a9a672aae%7C0%7C0%7C637180813657898313sdata=WjSVmpfmyFESKvSuQrvZnftVgEi%2FoZv93fHokE5xEyY%3Dreserved=0 This communication and any attachments may contain confidential information of Rocket Software, Inc. All unauthorized use, disclosure or distribution is prohibited. If you are not the intended recipient, please notify Rocket Software immediately and destroy all copies of this communication. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message:
Re: Cell Pool Services CSRC4EXP
Rob With all due respect to you as I have seen post about your XMEM share session I understand the caveat of AR programming as it relates to address spaces However nothing is 100 % generally SRB is the choice to do XMEM as it avoids these problems Can I ask where and when is your XMEM session in share I would like to see if I can attend thanks -Original Message- From: IBM Mainframe Discussion List On Behalf Of Rob Scott Sent: Sunday, February 23, 2020 1:34 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Cell Pool Services CSRC4EXP Personally I think that if your design requires you to alter the attributes of an address space which is not under your control, then it is likely that the design is flawed. Firing SRBs into random address spaces and issuing TRANSWAP just to perform some sort of memory management does not "smell right" to me. Rob Scott Rocket Software -Original Message- From: IBM Mainframe Discussion List On Behalf Of Joseph Reichman Sent: Sunday, February 23, 2020 3:43 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Cell Pool Services CSRC4EXP EXTERNAL EMAIL Then me just say what I do in the SRB The following XR R1,R1 Clear R1 as we cann't wait in SRB mode SYSEVENT TRANSWAP,ENTRY=BRANCH,ASID=(R4) Before I issue a get (actually access the cell) in a other address space double check we are okay L R1,ASCBOUCB-ASCB(R1) USING OUCB,R1 TMOUCBSFL,OUCBNSWis address space swapped in BZNOTSWAPno; -Original Message- From: IBM Mainframe Discussion List On Behalf Of Peter Relson Sent: Sunday, February 23, 2020 9:51 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Cell Pool Services CSRC4EXP Should just say data space Your logic confounds me. It can certainly be an address space. Whether it is an address space or data space, you have to do things right. page 217 ( chapter 13) of the assembler services guide Page and chapter references don't work too well if someone is looking at knowledge center. Let alone a reference without indicating the release. But I assume that you are referring to Figure 1 within Callable cell pool services -> Storage considerations. 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 Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA 02451 ■ Main Office Toll Free Number: +1 855.577.4323 Contact Customer Support: https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - http://www.rocketsoftware.com/manage-your-email-preferences Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy This communication and any attachments may contain confidential information of Rocket Software, Inc. All unauthorized use, disclosure or distribution is prohibited. If you are not the intended recipient, please notify Rocket Software immediately and destroy all copies of this communication. Thank you. -- 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: Cell Pool Services CSRC4EXP
Personally I think that if your design requires you to alter the attributes of an address space which is not under your control, then it is likely that the design is flawed. Firing SRBs into random address spaces and issuing TRANSWAP just to perform some sort of memory management does not "smell right" to me. Rob Scott Rocket Software -Original Message- From: IBM Mainframe Discussion List On Behalf Of Joseph Reichman Sent: Sunday, February 23, 2020 3:43 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Cell Pool Services CSRC4EXP EXTERNAL EMAIL Then me just say what I do in the SRB The following XR R1,R1 Clear R1 as we cann't wait in SRB mode SYSEVENT TRANSWAP,ENTRY=BRANCH,ASID=(R4) Before I issue a get (actually access the cell) in a other address space double check we are okay L R1,ASCBOUCB-ASCB(R1) USING OUCB,R1 TMOUCBSFL,OUCBNSWis address space swapped in BZNOTSWAPno; -Original Message- From: IBM Mainframe Discussion List On Behalf Of Peter Relson Sent: Sunday, February 23, 2020 9:51 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Cell Pool Services CSRC4EXP Should just say data space Your logic confounds me. It can certainly be an address space. Whether it is an address space or data space, you have to do things right. page 217 ( chapter 13) of the assembler services guide Page and chapter references don't work too well if someone is looking at knowledge center. Let alone a reference without indicating the release. But I assume that you are referring to Figure 1 within Callable cell pool services -> Storage considerations. 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 Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA 02451 ■ Main Office Toll Free Number: +1 855.577.4323 Contact Customer Support: https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - http://www.rocketsoftware.com/manage-your-email-preferences Privacy Policy - http://www.rocketsoftware.com/company/legal/privacy-policy This communication and any attachments may contain confidential information of Rocket Software, Inc. All unauthorized use, disclosure or distribution is prohibited. If you are not the intended recipient, please notify Rocket Software immediately and destroy all copies of this communication. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Cell Pool Services CSRC4EXP
Charles I think you are spot on Just wondering what Peter Relson might Say If he responds SRB and PC are sometimes not particle AR mode has its risk best to have a recovery Routine to address the rare case and maybe issue a SRB to swap back in I’m not at that point yet Thanks > On Feb 23, 2020, at 11:34 AM, Charles Mills wrote: > > There is at least a "technical" risk that the status of the address space > could change to swappable between your TM and whatever action you do based > on the determination of non-swappability, but for personal use software I > suppose you might find that risk acceptable. > > Does non-swappable guarantee "swapped in"? That's a serious question. I > don't know the answer. Can an already swapped-out address space be marked > non-swappable? Again, probably a manageable risk for personal use software. > > Charles > > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Joseph Reichman > Sent: Sunday, February 23, 2020 7:43 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Cell Pool Services CSRC4EXP > > Then me just say what I do in the SRB > > The following > >XR R1,R1 Clear R1 as we cann't wait in > SRB mode > SYSEVENT TRANSWAP,ENTRY=BRANCH,ASID=(R4) > > > Before I issue a get (actually access the cell) in a other > address space double check we are okay > > L R1,ASCBOUCB-ASCB(R1) > USING OUCB,R1 > TMOUCBSFL,OUCBNSWis address space swapped in > > BZNOTSWAPno; > > > -Original Message- > From: IBM Mainframe Discussion List On Behalf Of > Peter Relson > Sent: Sunday, February 23, 2020 9:51 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Cell Pool Services CSRC4EXP > > > Should just say data space > > > Your logic confounds me. It can certainly be an address space. Whether it is > an address space or data space, you have to do things right. > > > page 217 ( chapter 13) of the assembler services guide Page and > chapter references don't work too well if someone is looking at knowledge > center. Let alone a reference without indicating the release. > But I assume that you are referring to Figure 1 within Callable cell pool > services -> Storage considerations. > > 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 > > -- > 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: Cell Pool Services CSRC4EXP
There is at least a "technical" risk that the status of the address space could change to swappable between your TM and whatever action you do based on the determination of non-swappability, but for personal use software I suppose you might find that risk acceptable. Does non-swappable guarantee "swapped in"? That's a serious question. I don't know the answer. Can an already swapped-out address space be marked non-swappable? Again, probably a manageable risk for personal use software. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Joseph Reichman Sent: Sunday, February 23, 2020 7:43 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Cell Pool Services CSRC4EXP Then me just say what I do in the SRB The following XR R1,R1 Clear R1 as we cann't wait in SRB mode SYSEVENT TRANSWAP,ENTRY=BRANCH,ASID=(R4) Before I issue a get (actually access the cell) in a other address space double check we are okay L R1,ASCBOUCB-ASCB(R1) USING OUCB,R1 TMOUCBSFL,OUCBNSWis address space swapped in BZNOTSWAPno; -Original Message- From: IBM Mainframe Discussion List On Behalf Of Peter Relson Sent: Sunday, February 23, 2020 9:51 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Cell Pool Services CSRC4EXP Should just say data space Your logic confounds me. It can certainly be an address space. Whether it is an address space or data space, you have to do things right. page 217 ( chapter 13) of the assembler services guide Page and chapter references don't work too well if someone is looking at knowledge center. Let alone a reference without indicating the release. But I assume that you are referring to Figure 1 within Callable cell pool services -> Storage considerations. 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Cell Pool Services CSRC4EXP
Then me just say what I do in the SRB The following XR R1,R1 Clear R1 as we cann't wait in SRB mode SYSEVENT TRANSWAP,ENTRY=BRANCH,ASID=(R4) Before I issue a get (actually access the cell) in a other address space double check we are okay L R1,ASCBOUCB-ASCB(R1) USING OUCB,R1 TMOUCBSFL,OUCBNSWis address space swapped in BZNOTSWAPno; -Original Message- From: IBM Mainframe Discussion List On Behalf Of Peter Relson Sent: Sunday, February 23, 2020 9:51 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Cell Pool Services CSRC4EXP Should just say data space Your logic confounds me. It can certainly be an address space. Whether it is an address space or data space, you have to do things right. page 217 ( chapter 13) of the assembler services guide Page and chapter references don't work too well if someone is looking at knowledge center. Let alone a reference without indicating the release. But I assume that you are referring to Figure 1 within Callable cell pool services -> Storage considerations. 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: Cell Pool Services CSRC4EXP
Should just say data space Your logic confounds me. It can certainly be an address space. Whether it is an address space or data space, you have to do things right. page 217 ( chapter 13) of the assembler services guide Page and chapter references don't work too well if someone is looking at knowledge center. Let alone a reference without indicating the release. But I assume that you are referring to Figure 1 within Callable cell pool services -> Storage considerations. 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: Cell Pool Services CSRC4EXP
Peter I understand what you are saying in regards That it is not appropriate to address the target address space via alet As I saw Rob Scott’s post regarding the share session talking about xmem The diagram on page 217 ( chapter 13) of the assembler services guide is than some what erroneous where is specifies the cell storage data/address space B Should just say data space Thanks > On Feb 22, 2020, at 9:33 AM, Peter Relson wrote: > > > It would seem then if I would I want to have the actual storage in the > target address space I would have to schedule an SRB > > I could then issue CSRCxGET from a from that address space the cell > returned could be addressed in AR mode with using the ALET > > > Having no idea what the "target address space" is for your case, or what > ALET you are talking about, it is impossible to answer. I do not choose to > guess. > > The service does not touch the cell, and does not care about how the cell > is addressed. That is up to you. The "get" service returns to you the > address of the cell. That's it. > As I wrote, the only ALET that the service cares about is the control > ALET, in whatever way you have set things up so that that ALET can be > used. > > In general, it is not appropriate to address another address space by > ALET, unless you can guarantee that that space is non-swappable (or unless > the ALET is for primary or home or, in many cases, secondary). > > 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: Cell Pool Services CSRC4EXP
It would seem then if I would I want to have the actual storage in the target address space I would have to schedule an SRB I could then issue CSRCxGET from a from that address space the cell returned could be addressed in AR mode with using the ALET Having no idea what the "target address space" is for your case, or what ALET you are talking about, it is impossible to answer. I do not choose to guess. The service does not touch the cell, and does not care about how the cell is addressed. That is up to you. The "get" service returns to you the address of the cell. That's it. As I wrote, the only ALET that the service cares about is the control ALET, in whatever way you have set things up so that that ALET can be used. In general, it is not appropriate to address another address space by ALET, unless you can guarantee that that space is non-swappable (or unless the ALET is for primary or home or, in many cases, secondary). 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: Cell Pool Services CSRC4EXP
Peter
Thanks it would seem then if I would I want to have the actual storage in the
target address space I would have to schedule an SRB
I could then issue CSRCxGET from a from that address space the cell returned
could be addressed in AR mode with using the ALET
> On Feb 21, 2020, at 3:33 PM, Peter Relson wrote:
>
> What is the question? There is no question within the post.
>
> The cell storage (as opposed to the storage for the control structures
> managing the cell storage, which can be thought of as the "anchor" and the
> "extent") is not touched by the service. There is one ALET used for the
> suite of services. That is referred to as the control ALET ("cntl_alet").
> It applies to both the anchor and the extent. As one would expect, it
> does not apply to the cell storage. Whether the ALET represents an address
> space or data space is unimportant to the system.
>
> What part of the documentation is unclear, so that we can improve it
> appropriately?
>
> 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: Cell Pool Services CSRC4EXP
What is the question? There is no question within the post.
The cell storage (as opposed to the storage for the control structures
managing the cell storage, which can be thought of as the "anchor" and the
"extent") is not touched by the service. There is one ALET used for the
suite of services. That is referred to as the control ALET ("cntl_alet").
It applies to both the anchor and the extent. As one would expect, it
does not apply to the cell storage. Whether the ALET represents an address
space or data space is unimportant to the system.
What part of the documentation is unclear, so that we can improve it
appropriately?
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
Cell Pool Services CSRC4EXP
The documentation for cell pool services the anchor and extent can reside in one address space while the actual storage in other address space and I guess than the ALET parm would specify what address space/data space the anchor/extent reside If however the Cell pool storage as well reside in a different address space I guess they would have to be addressed by an access register containing that alet -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
