>These User Address Spaces could then use the
>SPACE Token to retrieve the ALET of te Server Address Space.

No, but the user address space could use the space token to add the space
to its access list, the output of which is an ALET that can be used to
reference that space. You have to be authorized to add an address space to
your access list, and that address space has to be non-swappable.

Once you have an ALET representing an address space, you can specify that
on the STORAGE OBTAIN.

The above really has nothing to do with STORAGE OBTAIN but rather with the
way ALETs work.

As with any cross-memory obtain for task-related (private) storage, the
"owner" is a task in the address space of the storage, likely the
cross-memory resource-owning task the address of which is in ASCBXTCB.

The more common usage is far simpler. After a space-switch PC, the target
routine obtains storage in the primary address space of the caller, using
ALET=1 (assuming the PC was set up such that new SASN = old PASN) or in
the home address space using ALET=2. Neither ALET=1 nor (in z/OS) ALET=2
requires any access list operations on the part of the user.

If you're asking these questions, you might be trying to do something that
you don't need to do. If you need storage in the client space, it would be
far more typical to PC there, passing whatever parameters need to be
provided, and do a "normal" STORAGE OBTAIN within the PC target routine.

>it seems to me the example is missing a SAC instruction when it accesses
the storage.

There was a SAC to AR ASC mode right after the BAKR upon entry. No
additional SAC is required.

>If the User address space space terminates without issuing STORAGE
RELEASE,
>will the Server Address Space have addressability to the storage area ?

The storage in your example is owned by the server address space.
Termination of the user address space does not affect that. So the answer
is "yes".

>This seems to me to be an integrity exposure ?

Aside from the fact that all of these operations are restricted to
authorized callers (hence there usually is no concept of an integrity
exposure as they are responsible for doing the right thing), there is no
exposure. Termination of the owning space (the server in your example)
results in the ALET by which the user was accessing that space becoming
invalid. Thus, upon termination of the server, the user cannot access that
storage. And if the user space terminates, it is proper that the server
can still access the storage that it owns.

Peter Relson
z/OS Core Technology Design

Reply via email to