On Sat, 24 Aug 2024 13:12:10 +0000, Peter Relson wrote: > >Regarding REFRPROT/NOREFRPROT: >The "no" version had to be provided and had to be the default, for >compatibility reasons. >The refreshable attribute had always been ignored by MVS / OS/390 / z/OS so >there were plenty of cases where modules had been marked refreshable that >weren't. >In most cases, compatibility concerns win over modernizing. > In the long term, that design principle leads to instability and complex documentation, difficult to understand, rife with "should ... unpredictable" where "must" would be better. As a programmer I am grateful whenever a system upgrade discloses my previously latent coding errors.
The REFRPROT behavior with *no*option* should have been introduced *before* the REFR option was added to the Loader. If so, no compatibility concern would have arisen. Short of that, I wished for finer granularity of the option. If REFRPROT were a JOB statement option, I would have used it. (REFRPROT should always dominate NOREFRPROT.) Was there once a concern that REFRPROT could cause storage fragmentation because small refr and norefr modules can not share pages? -- Thanks, gil ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
