Is that true for address spaces with non-reusable ASIDs?

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3

________________________________________
From: IBM Mainframe Discussion List <[email protected]> on behalf of 
Charles Mills <[email protected]>
Sent: Wednesday, September 26, 2018 12:20 PM
To: [email protected]
Subject: Re: ECB in XMEM Post

Definitely take a look at IEAMSXMP *if you will always be running on a 
supported version of z/OS.*

As I understand things it is impossible to do a perfect job of X-memory POST. 
There is no way to write code that with absolute certainty will not POST after 
its partner program has terminated and been replaced by some other process -- 
and thus "POST" into the middle of some unrelated code or data. You can do a 
pretty good job -- but with z/OS one can certainly argue that pretty good is 
not good enough.

Charles


-----Original Message-----
From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf 
Of Rob Scott
Sent: Wednesday, September 26, 2018 7:02 AM
To: [email protected]
Subject: Re: ECB in XMEM Post

I would be concerned in the fact that cross-memory POST is only deemed safe in 
certain circumstances.

I believe that normal cross-memory POST does not validate the ECB-owning 
address space STOKEN or TCB token.

IBM do offer IEAMSXMP which is a safe cross-memory POST protocol if 
pause/release or PC-ss cannot be used.


-----Original Message-----
From: IBM Mainframe Discussion List <[email protected]> On Behalf Of 
Joseph Reichman
Sent: Wednesday, September 26, 2018 2:31 PM
To: [email protected]
Subject: Re: ECB in XMEM Post

Rob

This is just a question is your comment based on the fact the ECB might be in 
pageable non/fixed storage and has potential for s0c4

Thanks



> On Sep 26, 2018, at 9:23 AM, Rob Scott <[email protected]> wrote:
>
> Both Pause/Release and PC-ss are supported in SRB mode.
>
> The fact that you are in recovery code (and possibly unsure of the status of 
> both ECB-owner and client) makes me believe that cross-memory POST is even 
> more undesirable.
>
> Not saying that it cannot be done with cross-memory POST, but Pause/Release 
> offers more environmental validation prior to execution and encapsulating a 
> PC-ss "POST" function isolates the recovery code from ECB-owner architecture 
> and may allow recovery code to run problem state.
>
> As ever in the case of things like this, it is never what you *intend* to do 
> that causes the problem......
>
> -----Original Message-----
> From: IBM Mainframe Discussion List <[email protected]> On
> Behalf Of Joseph Reichman
> Sent: Wednesday, September 26, 2018 1:23 PM
> To: [email protected]
> Subject: Re: ECB in XMEM Post
>
> You are right as it kills all registers besides 9 If memory serves me
> right I think the for the system or PC call
>
> I know you are going to scream at me but the reason I choose the post
> is because I’m posting This from a recovery routine as I don’t know
> whether it’s TCB mode or SRB I’m using the system call I.E pc I am
> passing the SDWA storage area back in the 3 byte 24 bit comp code area
> The 3 byte comp code makes this convenient for me
>
>
>> On Sep 26, 2018, at 8:11 AM, Rob Scott <[email protected]> wrote:
>>
>> Please be aware that cross-memory POSTs are not ideal and if possible I 
>> would consider a redesign of your code to use other methods - for example :
>>
>> (1) Pause/Release
>> (2) PC-ss service into ECB-owner ASID to issue POST on caller behalf
>>
>> Just my 2c.
>>
>> Rob Scott
>> Rocket Software
>>
>> -----Original Message-----
>> From: IBM Mainframe Discussion List <[email protected]> On
>> Behalf Of Joseph Reichman
>> Sent: Wednesday, September 26, 2018 1:01 PM
>> To: [email protected]
>> Subject: Re: ECB in XMEM Post
>>
>> Sorry I misunderstood
>> So if Address Space A would like to post Address B the ECB must be
>> addressable to to B as that is the Target the ASCB is that of the
>> target Address space B the ECB can be B private area in A all I need
>> is the address of the ECB even in private and ASCB of B
>>
>> Thanks
>>
>>
>> On Sep 26, 2018, at 7:41 AM, Peter Relson <[email protected]> wrote:
>>
>>>> This is just another way of saying that for XMEM the ECB is in CSA
>>>> right
>>> ?
>>> No, not right.
>>>
>>> What within the wording "must be addressable from the address space
>>> identified by the ASCB parameter" makes you say that? Storage
>>> addressable from an address space includes common storage (whether
>>> CSA or SQA) and private storage of the address space. The ECB can be
>>> in any of those areas.
>>>
>>> Peter Relson
>>> z/OS Core Technology Design
>>>
>>>
>>> --------------------------------------------------------------------
>>> -- For IBM-MAIN subscribe / signoff / archive access instructions,
>>> send email to [email protected] with the message: INFO
>>> IBM-MAIN
>>
>> ---------------------------------------------------------------------
>> - For IBM-MAIN subscribe / signoff / archive access instructions,
>> send email to [email protected] 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://secure-web.cisco.com/1S5OB0TeGz1u-8gltQlq3-QRDxht0yVSx8vz16COsyhPIAk_IfOSBRPuokx-Zyvo6YP7e3t1G_4Cn7vnY2tDf10U8yV_bPvzZC0Qg5mPiTt_q_fb7gN0sIdYO4ncRqXCqHaqtg4TzQomlEmEAs68mrmrhsRDZnr-blgmIMkcyA1h9nBIOmo2y2c4wYAgaIuJPn8WQfn94a4KnX2xfqyH62VjaLLWONZAa2_X65t0DYISUOfcySM3wc3bF6YEC61ZbU3sH2rC-PSuYItXGjRYf7tkDMl494874oVBmq6SRKjRiRsDrYHLfO67lzC4-1_W-DP9pJc2RNjFTi05y6kN9tL7ZgNI1268jNWBW1yPIcbv05oY-RDgo9iyYC3vr45OVfZtzIj87k-8v0mjvGhY9Qp4R0a9tMxONfQkEw5dhUJo3iACy_hsMs-5WAZTRgpyW9yvw8uwNjp3McbXcONU6Hw/https%3A%2F%2Fna01.safelinks.protection.outlook.com%2F%3Furl%3Dhttps%253A%252F%252Fmy.r
>> ocketsoftware.com%2FRocketCommunity%2FRCEmailSupport&amp;data=02%7C01
>> %7CRScott%40ROCKETSOFTWARE.COM%7Cd997bf72252b48399ec008d623b4583b%7C7
>> 9544c1eed224879a082b67a9a672aae%7C0%7C0%7C636735654825882842&amp;sdat
>> a=FCzgvDLPFFnT99MDixYUBiA4e1Gnz39JBPLIeRNLApE%3D&amp;reserved=0
>> Unsubscribe from Marketing Messages/Manage Your Subscription
>> Preferences -
>> https://secure-web.cisco.com/19ZO-_6shoYlHy8IgG8sPPIiMfmLeefHQlvZHXEfKTFxW5jTT2qqFmCIGDDAri0oy95auIxDm0cqrVqcBUWi2QUve2F-y5xZegFJ7tL2RQzrptEN9O5kRUQv6vV9hsc5-RJN-EACN6sfdC4t26kqQQrOzYJBRPPsBUYoSy1yItT8RfDnphXHIlwjKON99QKv7LkQp5rCCGCMRzKVp92p0uvL4uzsPrWVlK_X2aOLjsKzLh5XUqC2uqN8j-7QbgX71v-XhVWHaIICL-0pIsZFvPwRL_QqD_ZUE2vX1SHvp6LYtedCUH6wtzJqZPqlpLeqT2Rg0IVdPWyR-WFwPtqBPJOW31vA69NTN_A7MtLkfdZmfumiKuQXtbM-bDw5PXDpx3p-J3DcrmvDNmoQmY43jgYst6r_Hqi1kvKtn0j_5D0Kb0qKYkVAJEswr3d7LB0IT0reA6qliM_QhFUJan9xFWw/https%3A%2F%2Fna01.safelinks.protection.outlook.com%2F%3Furl%3Dhttp%253A%252F%252Fwww.r
>> ocketsoftware.com%2Fmanage-your-email-preferences&amp;data=02%7C01%7C
>> RScott%40ROCKETSOFTWARE.COM%7Cd997bf72252b48399ec008d623b4583b%7C7954
>> 4c1eed224879a082b67a9a672aae%7C0%7C0%7C636735654825882842&amp;sdata=c
>> BXxvzlrU3dvgZwkYz7B3LWOz7HGGwKFiTt7uPYlsZ4%3D&amp;reserved=0
>> Privacy Policy -
>> https://secure-web.cisco.com/19ZO-_6shoYlHy8IgG8sPPIiMfmLeefHQlvZHXEfKTFxW5jTT2qqFmCIGDDAri0oy95auIxDm0cqrVqcBUWi2QUve2F-y5xZegFJ7tL2RQzrptEN9O5kRUQv6vV9hsc5-RJN-EACN6sfdC4t26kqQQrOzYJBRPPsBUYoSy1yItT8RfDnphXHIlwjKON99QKv7LkQp5rCCGCMRzKVp92p0uvL4uzsPrWVlK_X2aOLjsKzLh5XUqC2uqN8j-7QbgX71v-XhVWHaIICL-0pIsZFvPwRL_QqD_ZUE2vX1SHvp6LYtedCUH6wtzJqZPqlpLeqT2Rg0IVdPWyR-WFwPtqBPJOW31vA69NTN_A7MtLkfdZmfumiKuQXtbM-bDw5PXDpx3p-J3DcrmvDNmoQmY43jgYst6r_Hqi1kvKtn0j_5D0Kb0qKYkVAJEswr3d7LB0IT0reA6qliM_QhFUJan9xFWw/https%3A%2F%2Fna01.safelinks.protection.outlook.com%2F%3Furl%3Dhttp%253A%252F%252Fwww.r
>> ocketsoftware.com%2Fcompany%2Flegal%2Fprivacy-policy&amp;data=02%7C01
>> %7CRScott%40ROCKETSOFTWARE.COM%7Cd997bf72252b48399ec008d623b4583b%7C7
>> 9544c1eed224879a082b67a9a672aae%7C0%7C0%7C636735654825882842&amp;sdat
>> a=XO3065WD6tP9ATks5b2bWQFD6%2FaYxgp8y%2FY9Zw7c3w8%3D&amp;reserved=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 [email protected] with the message: INFO
>> IBM-MAIN
>
> ----------------------------------------------------------------------
> For IBM-MAIN subscribe / signoff / archive access instructions, send
> email to [email protected] with the message: INFO IBM-MAIN
>
> ----------------------------------------------------------------------
> For IBM-MAIN subscribe / signoff / archive access instructions, send
> email to [email protected] with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions, send email to 
[email protected] with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN

Reply via email to