I have always understood that refreshable always meant that the
executable could be replaced by the copy from a load library at anytime,
which probably could be interpreted as between the execution of any two
instructions. I thought of reentrant as a considerably looser
definition, and presumably allowed self-modifying programs as long as
concurrent usage of the executable in memory was not adversely
affected. Implementing CICS's SIT option RENTPGM=PROTECT seemed to
require reentrant load modules to actually be refreshable.
Gary Weinhold
Senior Application Architect
DATAKINETICS | Data Performance & Optimization
Phone +1.613.523.5500 x216
Email: [email protected]
Visit us online at www.DKL.com
E-mail Notification: The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system.
__________
On 2016-02-17 16:51, Paul Gilmartin wrote:
On 2016-02-17 10:38, Jim Mulder wrote:
The administrator should be specifying REFRPROT in PROGxx.
The only reason we made it an option was concern that an installation
might have self-modifying programs which were incorrectly had the
REFR attribute, and we didn't want that to be a migration issue for
z/OS 1.9, where REFRPROT was introduced.
Your use of "should" suggests that you believe REFRPROT should be the
default? Is it? Such things can be phased in as I believe was done
or is in progress for protection against user key CSA.
-- gil
