Paul Gilmartin wrote: <begin snippet> Conceptually, any user who has done a BLDL and saved the TTR has a connection to the member. PDSE merely formalized the process. </end snippet>
and this point is an important one. One of the crucial differences between a traditional PDS and a PDSE is that, while the gas in a PDS is removable only by reorganizing it, the gas in a PDSE is largely eliminated dynamically, by reusing the space occupied by deleted members. This laudable effort of course gives rise to another instance of an old and very familiar class of problems. If, say, I LOAD a copy of the reentrant module MCGUFFIN and you then LOAD a copy of MCGUFFIN, your LOAD is converted into a virtual one: a usage count is incremented and you are provided with the address of the same copy of MCGUFFIN that I am using. My DELETE then decrements the usage counter and iff doing so reduces that count to zero is the strorage occupied by MCGUFFIN freed/recovered. Now PDSE management makes available all of the usage-count facilities needed to ensure that DELETE operations are virtual or real as appropriate if they are used. If they go unused the space in a PDSE will be exhausted. Still, there is a significant net gain. PDSEs can be managed correctly, while PDSs cannot; and this brings me to my single criticism of Paul Gilmartin's language. The weasel word 'merely' in "PDSE merely formalizes the process" is inappropriate. This change was a large step forward in an imperfect world. Clots will still be able to botch things up---How not?---but the tools are available for those who wish to use them. Here, as always with this class of problems, if you increment a usage count you must also decrement it. 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
