With the IARVSERV macro, the SHARE and CHANGEACCESS parameters
can change the views type of storage access. For SHARE, the current
storage attribute of the source data affects the outcome of the target.
Table 1 shows the permitted target views for different
combinations with the source. A NO in the table means that an abend
will occur if you request that target view with the current source
view. For CHANGEACCESS, all combinations are permitted.
Table 1. Allowed Source/Target View
Combinations for Share| Current |
Requested Target View |
|---|
| Source View |
READONLY |
SHAREDWRITE |
UNIQUEWRITE |
TARGETWRITE |
HIDDEN |
LIKESOURCE |
| READONLY |
Yes |
No |
Yes |
Yes |
Yes |
Yes |
| SHAREDWRITE |
Yes |
Yes |
Yes |
Yes |
Yes |
Yes |
| UNIQUEWRITE |
Yes |
Yes |
Yes |
Yes |
Yes |
Yes |
| TARGETWRITE |
No |
No |
Yes |
No |
No |
Yes |
| HIDDEN (Shared) |
No |
No |
No |
No |
No |
Yes |
| Non-Shared |
Yes |
Yes |
Yes |
Yes |
Yes |
Yes |
| HIDDEN (Non-Shared) |
No |
No |
No |
No |
No |
Yes |
The following apply when using IARVSERV SHARE when changing storage
access:
- For source views to be either UNIQUEWRITE or TARGETWRITE, the
processor must have the Suppression-On-Protection (SOP) hardware feature,
and a previous IARVSERV SHARE must have created a view of UNIQUEWRITE
or TARGETWRITE.
- For target views to be TARGETWRITE, the processor must have the
SOP hardware feature. If a request is made to create a TARGETWRITE
view and the SOP feature is not installed, the request fails with
a return code of 8.
- For target views to be UNIQUEWRITE, the SOP hardware feature must
be installed. Also, the request must not specify COPYNOW. If the
request specifies COPYNOW, or the SOP feature is not installed, a
UNIQUEWRITE view is not established, and a separate copy of the data
is made.
- For target views created with LIKESOURCE on IARVSERV SHARE, the
system propagates explicit page protection from the source to the
target view.
- For source pages that are not shared, if the page is page-protected,
the view created for that page is a SHAREDWRITE view, but the view
is flagged as an explicitly protected view (one that cannot be modified).
The following apply when changing the storage access with IARVSERV
CHANGEACCESS:
- To remove hidden status, you must use an IARVSERV CHANGEACCESS,
FREEMAIN, or DSPSERV DELETE macro.
- To remove explicit read-only protection status, you must use an
IARVSERV CHANGEACCESS, FREEMAIN, DSPSERV DELETE, or PGSER UNPROTECT
macro.
- If a hidden page is hidden because of loss of access to 'mapped'
data (such as through DIV UNMAP), and, if the page is changed from
hidden, the data in the page might be lost.
- Hidden pages cannot be released via a PGSER RELEASE or DSPSERV
RELEASE macro. An attempt would result in an abend with the same
reason code as is used for protected pages.
- Issuing an IARVSERV UNSHARE macro for the original mapped page
causes the data to be retained for that page. The data for the other
sharing pages is lost. References to hidden pages cause an X'0C4' abend,
and references to lost pages cause in a X'028' abend.
- Page-fixed pages and DREF pages cannot be made TARGETWRITE, UNIQUEWRITE,
or HIDDEN.