Description: The IOSSPOF macro changed to conditionally
obtain the returned SPOFAREA in a different subpool depending on the
caller's PSW key. This may cause the caller, depending on their current
PSW key, to be required to change to a different PSW key if they want
to update the storage. In addition, certain PSW key callers can no
longer rely on the storage automatically being freed when the task
ends. The subpool number continues to be returned in the SPOFAREA_SUBPOOL
so that it can be used when the storage is freed.
The specific changes are:
- Key 0-7 callers: The returned SPOFAREA mapped by IOSDSPOF is obtained
in subpool 252, which is key 0 storage, non-fetch-protected, and is
associated with the jobstep task.
- Key 8-15 callers: The returned SPOFAREA mapped by IOSDSPOF continues
to be obtained in subpool 1, which is fetch-protected storage with
a key equal to the TCB key and is associated with the issuing task.
The specific restrictions are:
- Key 0-7 callers cannot rely on the SPOFAREA storage automatically
being freed when the task ends. The area must now be explicitly freed
and the caller must meet the state, key, and APF-authorization requirements
for freeing from subpool 252.
- Key 1-7 callers must change to Key 0 in order to update the returned
SPOFAREA storage.
- Key 8-15 callers must be in the PSW key of the TCB in order to
access the SPOFAREA storage.
| Element or feature: |
BCP. |
| When change was introduced: |
z/OS V2R1, and on z/OS V1R13 and z/OS V1R12 with APAR OA37035. |
| Applies to migration from: |
z/OS V1R13 and z/OS V1R12 both without APAR
OA37035 applied. |
| Timing: |
Before installing z/OS V2R1. |
| Is the migration action required? |
Yes, if you have code that invokes the IOSSPOF
macro in a PSW key of 0-7. |
| Target system hardware requirements: |
None. |
| Target system software requirements: |
None. |
| Other system (coexistence or fallback) requirements: |
None. |
| Restrictions: |
None. |
| System impacts: |
None. |
| Related IBM Health Checker for z/OS check: |
None. |
Steps to take: For any program that invokes the IOSSPOF
macro in a PSW key of 0-7, ensure the following restrictions are followed:
- Key 0-7 callers: Because the subpool used for the SPOFAREA has
changed from being associated with the issuing task to being associated
with the jobstep task, be sure to free the storage if your task is
not the jobstep task. In addition, make sure your storage-free invocation
meets the state, key, and APF-authorization requirements for freeing
from subpool 252.
- Key 1-7 callers: If the program attempts to write to the returned
SPOFAREA, the program must switch to key 0 to update the area.
Reference information: For additional information, see z/OS MVS Programming: Authorized Assembler Services Reference EDT-IXG.