Paul Gilmartin wrote:
To get complete protection of all RENT modules, you must use the
CsvRentProtect DIAG trap. That uses PGSER PROTECT to protect the modules
once they're loaded. I don't recommend that setting on systems older
than z/OS V1R8 because there are several popular IBM programs, residing
OK. Write-protected pages, not subpool.
Is it likely that with evolution the behavior of those two options
will become the default, and the list of exceptions will shrink?
I suppose the transition will never be complete because of "dusty
deck" concerns.
I've never understood why the CsvRentSp252 DIAG trap is necessary. What
is the rationale for ignoring the RENT attribute for unauthorized
programs? Authorized or not, a RENT program that modifies itself in an
unserialized way has a bug that could have serious ramifications for the
application. IMHO, by ignoring the RENT option for unauthorized
programs, the operating system does their owners a great disservice.
Currently, there is a "refreshable" attribute that the binder
understands. That attribute is completely ignored by the operating
system. If the distinction between RENT and REFR were surfaced in
contents supervisor control blocks (there is a CDRENT flag bit in the
CDE but no CDREFR flag bit), then it's conceivable IBM could, without
too much effort, make REFR imply page protection. With that, we would
not need the CsvRentProtect DIAG trap and its associated exception
table! Our platform could do away with module overlays once and for all!
It would be tremendous RAS improvement!
Some non-IBM systems can mark segments as I-fetch only and D-fetch
only. Does z/Series have this capability? It instantly traps on
wild-branch-into-data. Might also provide a guideline for cache
management.
No similar capability. The I- or D- fetching occurs as a result of a
reference to storage, either by PSW (or other instruction fetch such as
target of EX or TR/TRT translate table) or instruction operand (data).
The recent discussion here and in links mentioned "very small"
programs, which might load instructions and data into the same
cache line. I assume this could happen even in a very large
program, wherever instructions abut data.
Data and instructions don't mix, no matter how large or small the
program. Some years ago, we found a large, non-RENT program with
hundreds of subroutines, each of which performed linkage using a
sequence similar to:
| DC 16F'0'
|Label DC 0H
| STM R0,R15,Label-64
| .
| . (code here)
| .
| LM R0,R14,Label-64
| BR R14
(Yuck!) It probably performed reasonably well when it was written. But
on today's hardware, it was a nightmare. This program was made reentrant
and has not been a problem since.
.. Would use of "DS 255C"
be a good way to avoid the performance impact? Of course this
could be ovecome by events if future hardware has a different
cache line size.
It would avoid the I-cache D-cache performance issues at the cost of
increased module size, which has its own set of issues (slower module
fetch, increased cache utilization, increased paging, base register
problems for code using based branches, etc.). Reentrancy is almost
always the better approach.
Will CSV and storage management ever allow load modules and data
to occupy the same page? If so, a program might need to be
protected with neutral zones on both ends.
Programs loaded into SP 252 are loaded into what are usually considered
to be "program-only" pages. No so for programs loaded into SP 251.
Programs loaded from a PDSE program object library are (usually)
page-aligned and occupy a whole number of pages (default binder options
are NOPACK, NOPRIME). Not so for programs loaded from a PDS load library.
Does EX count as an I-fetch or a D-fetch? (Could even be model-
dependent)
This question is so easily answered by reading PoOp, I'm surprised you
asked it in this forum. It's already been answered above.
--
Edward E Jaffe
Phoenix Software International, Inc
5200 W Century Blvd, Suite 800
Los Angeles, CA 90045
310-338-0400 x318
[EMAIL PROTECTED]
http://www.phoenixsoftware.com/
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
