Richard,

Please avoid RUCSA for new development at all costs. User-key common storage is 
a huge security/integrity exposure to the system.
RUCSA was implemented to provide relief to customers that rely on software that 
still uses user-key CSA where updating the code was impossible (maybe lost) or 
extremely difficult and they needed more time to migrate to alternative 
solutions.

Depending on what you need to achieve there are some really nifty XCF services 
that can enable inter-address space communication, with the added benefit of 
possible sysplex-wide scope.

For example, take a look at IXCSEND and IXCRECV services - I know of a few ISV 
products that have replaced a lot of PC-ss style code with these services.

Rob Scott
Rocket Software

From: IBM Mainframe Discussion List <[email protected]> On Behalf Of 
Richard Zierdt
Sent: Wednesday, September 4, 2024 11:40 PM
To: [email protected]
Subject: Re: POSTing a WAIT in another Address Space; POST ASCB= parameter; 
S602 Abend

EXTERNAL EMAIL



OK - both techniques (now) work. POST . . . ASCB wants the ASCB, not the 
address of the ASCB. L rx,ASCB then POST . . . ASCB=(rx) works. Same with the 
ECB (ECB in a register, not the address of an ECB). The manual might have been 
clearer about this. I don't see how LA of anything would work, yet the macro 
supports it.

IEAMSXMP works as well. Here, like POST, the ECB *is* the ECB, not the address 
of. The TTOKEN parameter, being 16 bytes long, won't fit in a register, so it 
follows that that parameter must be the address of TTOKEN. All tokens (ECB, 
ASCB, TTOKEN) were passed between address spaces via Name-Token (IEANTCR, 
IEANTRT services).

BTW, while both POST (XM) and IEAMSXMP require supervisor state, key 0 is not 
required, except for POST LINKAGE=BRANCH form.

And PAUSE, RELEASE is another communication tool. I'll study those next. If 
they support XM, even better.

The CS instruction is interesting, but I'm not sure how it would work in a XM 
environment. ALET of the target address space?

I looked-up RUCSA. Yes, IBM discourages it, but the concept is interesting.

In any event, I've got plenty to work with. Thanks to everyone for their 
suggestions, guidance.

Richard Zierdt

________________________________
From: IBM Mainframe Discussion List 
<[email protected]<mailto:[email protected]>> on behalf of 
Charles Mills <[email protected]<mailto:[email protected]>>
Sent: Wednesday, September 4, 2024 6:17 PM
To: [email protected]<mailto:[email protected]> 
<[email protected]<mailto:[email protected]>>
Subject: Re: POSTing a WAIT in another Address Space; POST ASCB= parameter; 
S602 Abend

This Message Is From an External Sender
This message came from outside your organization.


RUCSA is such a bad idea that IBM charges you extra for the feature just to try 
to discourage you from using it.

I am not going to mention names out of school but I do know that the powers 
that be resisted even adding the feature. (A few customers demanded it, and you 
know who won THAT argument.)

Charles

On Wed, 4 Sep 2024 16:34:03 -0500, Mike Schwab 
<[email protected]<mailto:[email protected]>> wrote:

>How about RUCSA (or CSA)? Common memory addressable by all address
>spaces but only used by affected address spaces.
>https://urldefense.com/v3/__https://www.ibm.com/docs/en/zos/2.4.0?topic=overview-virtual-storage-address-space-esa-extensions__;!!HaceldhrWm2T3s6H!wIJtSQIUEZwEOnldqVxz_p4osJ_H6C2G-yw_QeopyA_99hTF6nnIGbq-NPx__I5oNNTW7R-8gkQYW2288lGriG42bSM$<https://urldefense.com/v3/__https://www.ibm.com/docs/en/zos/2.4.0?topic=overview-virtual-storage-address-space-esa-extensions__;!!HaceldhrWm2T3s6H!wIJtSQIUEZwEOnldqVxz_p4osJ_H6C2G-yw_QeopyA_99hTF6nnIGbq-NPx__I5oNNTW7R-8gkQYW2288lGriG42bSM$>

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


Confidentiality Warning/Avertissement de confidentialité:

This message is intended only for the named recipients. This message may 
contain information that is privileged or confidential. If you are not the 
named recipient, its employee or its agent, please notify us immediately and 
permanently destroy this message and any copies you may have. Ce message est 
destiné uniquement aux destinataires dûment nommés. Il peut contenir de 
l'information privilégiée ou confidentielle. Si vous n'êtes pas le destinataire 
dûment nommé, son employé ou son mandataire, veuillez nous aviser sans tarder 
et supprimer ce message ainsi que toute copie qui peut en avoir été faite.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected]<mailto:[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://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 [email protected] with the message: INFO IBM-MAIN

Reply via email to