For address spaces known to always be non-swappable, how about ALESERV
ADD and just load the returned ALET into an AR, then SACF 512? My
code that does that has never failed (yet). What are the risks, other
than the obvious one of the target A/S going away while the code is
running?
Come to think of it, what happens to WORKUNIT entries if the target
A/S goes away? I expect S0C4 with some obscure reason code, when
referencing an ALET for an A/S which went away.
/Leonard
Peter Relson wrote on 9/20/2023 7:30 AM:
Adam J wrote
<snip>
Given the proper authorization, you can:
- Issue an AXSET, specifying a value of 1
- Issue an SSAR instruction identifying the target address space as the
secondary address space
- Use MVCP / MVCS instructions to copy data between your primary address space
and the secondary address space
</snip>
While that is "true" (aside from the fact that SSAR would be rejected if this
is a reusable ASID and would need to be SSAIR),
this is not something you should do. And your "connection" could break at any
instant unless the target address space is both non-swappable and not memtermable.
Adam J wrote
<snip>
There is also the technique of using the special ALET value of x'00000001' and
using AR mode to reference data from another address space.
</snip>
That too is a bad idea unless you have addressability to this other space as your
"secondary" address space (which typically would be after a space-switch PC to
"you").
z/OS does not support the concept of "address space faults" (i.e., the program
check you get when referencing storage in another address space when that address space
is swapped out). This is one of the reasons why cross-memory servers are required to be
in non-swappable address spaces.
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
