I think that z/OS and its immediate predecessors already make most of what is needed available.
Only in special circumstances do I see or, if I see them, read Shmuel's posts; but I found one---It is one of his characteristic "Nonsense!" posts---in this thread. It was directed at an earlier post of mine, and it is therefore a convenient starting point for discussion. My comment that elicited his "Nonsense!" response suggested very briefly that the device of making and marking a load module or program object reentrant or, better, refreshable could be used to share code across LPAR boundaries. His response was that things do not work that way. If he had instead written that they do not always work that way, I should have passed over his post silently, as banal but correct and certainly inoffensive; but he elected to go for the jugular even though, as he must know, his knife-fighting skills are now much diminished. For many years, since OS/390 V4, I have used a scheme that adds sets of refreshable modules to the LPA dynamically in order to share them among several LPARs. It has always worked well; it continues to work under z/OS 2.1 as it has worked in the past; and the facilities of CSVQUERY remain available for ensuring that a dynamic LPA addition has succeeded. Multiple resident copies of an excecutable can sometimes be highly problematic. From perhaps 20 years ago I recall a situation in which an intellectually challenged client programmer had replaced an old, very simple but heavily used assembly-language data-vetting AP used under CICS with one of his own devising written in RPG, which could not then be made even quasi-reentrant under CICS, with truly disastrous results. Such problems are ordinarily easy to remedy individually when, for whatever reason, they occur; and when they do occur they cannot be ignored. That said, Timothy Sipples is clearly right in general: The use of significant system-software resources to identify and share bit-equivalent pages, even big ones, dynamically is not likely to pay for itself in a z/OS environment. The major optimizations are already in place. The z/OS ASM does not, for example, page out unaltered pages after doing so once initially; and it is able to make this distinction efficiently because there is hardware support for distinguishing altered/stored-into pages from unaltered ones. John Gilmore, Ashland, MA 01721 - USA ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
