Hello everyone, but particularly Rob, since he responded. Thank you for the
alternatives, including the SYS1.MACLIB(BLSACTV) service, which is news to me.
I don't see it documented in the guide or reference manuals, but the macro
itself contains a description, much like a reference manual entry. Would that
more macros were like this one.
I figured out what was going on with ALESERV. A program "A" can read data
from another address space "B", IF A is given B's STOKEN (not the ALET).
Program "A":
ALESERV ADD, STOKEN=(of Program B ) returns the ALET=alet to use to access
Program B (from within Program A).
A MODESET KEY=ZERO is needed only for the duration of the ALESERV. It is not
needed to copy data from B (which is all that is needed: a fast copy).
ALESERV will not work if CHKEAX=YES is specified, as R15 returns an 8:
"The caller is not EAX-authorized to the specified space"
I read your note warning about "peeking into another address space." For this
application, Program A is nonswappable, so that should allay some of the
concerns. In addition, an ESTAE(X) environment should handle the exceptions
you warn about. Also, could things have improved in the last 20 years?
The simplicity of a single ALESERV (albeit wrapped around MODESET) to get the
job done is very attractive. Of course, all that glitters is not gold, so I'll
keep Chris Craddock's and your warnings in mind.
Thanks again
Richard Zierdt
________________________________
From: IBM Mainframe Discussion List <[email protected]> on behalf of Rob
Scott <[email protected]>
Sent: Tuesday, October 1, 2024 4:45 AM
To: [email protected] <[email protected]>
Subject: Re: Cross-Memory Access: Can an Address Space be treated as a Data
Space using an ALET?
This Message Is From an External Sender
This message came from outside your organization.
Richard
Depending on what you are trying to accomplish, there are better options of
sharing memory between two address spaces.
If you own the code in both address spaces, then you could use shared memory
objects or even get ASID(A) to own a space-switch PC to return requested memory
contents in a buffer to its callers in ASID(B).
If you do not own the code in ASID(A) and are using PGMB in ASID(B) to look at
memory in ASID(A), then there are a couple of other techniques :
(o) ASID(B) schedules an SRB into ASID(A) to retrieve the memory - I have
example code to do this at :
https://urldefense.com/v3/__https://github.com/rscott-rocket/mxe__;!!HaceldhrWm2T3s6H!yn_W0TIms-5G8PGqU1Tm_h5t3EsbAEfTZA_3EY5bzsiCSQJayS-szXVGJaMrn9-EqZWb0BRuenYNFpO-yDcjGjq2kgtTqRMq-Y2jhbO7RV9URQ$
(there is also an allied Share presentation for this code)
(o) Use the BLSACTV service in SYS1.MACLIB (since z/OS 2.5) - this is actually
what we use for the SDSF "MEM" command.
Using CHKEAX=NO for address spaces outside of your control is not ideal - about
20 years ago on this very forum Chris Craddock (one of the original BMC
Mainview/Resolve developers) commented the following :
"This technique for peeking into another address space is very dangerous on a
number of levels. If the address space is out then any access to private area
pages will fail. If you take page faults in that space and you need to be
suspended then bind break processing may notice the target space is not set up
for cross memory access and abend you (S058?) likewise if the address space
terminates while you're looking at it. I would expect to bump into one or more
of the S058 or related abends with some regularity with this technique"
Note that all of the above alternative methods can be achieved in PSW keys
other than 0 (perhaps key2 or key4), which helps make your code safer as you
are less likely to overwrite other important system or common memory by mistake
and become "famous".
Rob Scott
Rocket Software
-----Original Message-----
From: IBM Mainframe Discussion List <[email protected]> On Behalf Of
Richard Zierdt
Sent: Tuesday, October 1, 2024 5:22 AM
To: [email protected]
Subject: Cross-Memory Access: Can an Address Space be treated as a Data Space
using an ALET?
EXTERNAL EMAIL
The goal is to read data from an address space (not a data space) using an ALET.
The idea is "Program A" creates its own ALET that another program ("Program B")
uses in its address space to read data from Program A's address space. Is this
possible ?
A summary of Program A code (AMODE31, RMODE24, authorized) is:
ALESERV EXTRACTH,STOKEN=stoken Returns STOKEN for the address space
MODESET KEY=ZERO Needed, or return code from ALESERV is not zero
ALESERV ADD AL=PASN,
STOKEN=stoken, input STOKEN
ALET=HomeALET, output ALET
CHKEAX=NO,
AL=PASN,
ACCESS=PUBLIC,
MF=(E,ALESERV)
SYSEVENT DONTSWAP make unswappable
WTOR sit on a WTOR so that Program B can access Program A's address
space
Result is HomeALET=x'01010038' which looks good, except that Program B gets an
0E0, Reason Code 29 (hex) abend using that ALET. "An ALET specified an access
list entry (ALE) that is not valid."
A summary of Program B code (AMODE31, RMODE24, authorized) is:
SAC 512 sets the ASC mode to AR mode
LAM 0,15,Zeros clear access registers
L R6,=x'00007000' load offset to data into GR6
LAM 6,6,=x'01010038' load ALET of Program A into AR6
Abend0E0 MVC Here,0(R6) copy data from Program A to Here
SAC 0 escape AR mode
Here ds CL32
SYSTEM COMPLETION CODE=0E0 REASON CODE=00000029 ACTIVE MODULE
ADDRESS=00000000_00007000 OFFSET=00000050 NAME=PROGRAMB DATA AT PSW 0000704A
- C0809A66 C084D21F C05C6000
AR/GR 0: 00000000/00000064 1: 00000000/00006FF8
2: 00000000/00000040 3: 00000000/008DBD64
4: 00000000/008DBD40 5: 00000000/008FB058
6: 01010038/00007000 7: 00000000/00FBB880
8: 00000000/008FD608 9: 00000000/008D0CB0
A: 00000000/01DE1E00 B: 00000000/00000001
C: 00000000/80007000 D: 00000000/00008000
E: 00000000/80FD66D8 F: 00000000/80007000
Any help appreciated; Thanks --
Richard Zierdt
----------------------------------------------------------------------
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://urldefense.com/v3/__https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport__;!!HaceldhrWm2T3s6H!yn_W0TIms-5G8PGqU1Tm_h5t3EsbAEfTZA_3EY5bzsiCSQJayS-szXVGJaMrn9-EqZWb0BRuenYNFpO-yDcjGjq2kgtTqRMq-Y2jhbNYcF5eyQ$
Unsubscribe from Marketing Messages/Manage Your Subscription Preferences -
https://urldefense.com/v3/__http://www.rocketsoftware.com/manage-your-email-preferences__;!!HaceldhrWm2T3s6H!yn_W0TIms-5G8PGqU1Tm_h5t3EsbAEfTZA_3EY5bzsiCSQJayS-szXVGJaMrn9-EqZWb0BRuenYNFpO-yDcjGjq2kgtTqRMq-Y2jhbOUh21ftg$
Privacy Policy -
https://urldefense.com/v3/__http://www.rocketsoftware.com/company/legal/privacy-policy__;!!HaceldhrWm2T3s6H!yn_W0TIms-5G8PGqU1Tm_h5t3EsbAEfTZA_3EY5bzsiCSQJayS-szXVGJaMrn9-EqZWb0BRuenYNFpO-yDcjGjq2kgtTqRMq-Y2jhbP6CXZ8Fg$
================================
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
Confidentiality Warning/Avertissement de confidentialite:
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
destine uniquement aux destinataires dument nommes. Il peut contenir de
l'information privilegiee ou confidentielle. Si vous n'etes pas le destinataire
dument nomme, son employe ou son mandataire, veuillez nous aviser sans tarder
et supprimer ce message ainsi que toute copie qui peut en avoir ete faite.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
