On the other hand. Not only the code that would have to be written but debugging it would be a nightmare without a "system" to start any trace or whatever debugging tools need to be loaded at IPL time. *AND* imagining at 0000 hours you re-ipl and it doesn't come up?There is no obvious (to me) of shooting this "bug" except to take a S/A dumpp. Of course uou need a system to fire up IPCS to shoot it with level 1 & 2. I am not saying its impossible but the likely hood of issues would be almost insurmountable without something like VM or the "ancient thing" called DSS. I sure would not want to be on any forefront with this system. I know IBM got the vsam catalog right with minimal issues (although there were some). But recoding everything that needs to access a PDSE at IPL time would not be for the fient of heart. Ed
--- On Mon, 10/25/10, Rick Fochtman <[email protected]> wrote: From: Rick Fochtman <[email protected]> Subject: Re: PDSE versus PDS To: [email protected] Date: Monday, October 25, 2010, 4:29 PM > > > --------------------------------------<snip>-------------------------------- > >> The decision not to support IPL-time use of PDSEs was an unconscionable >> one. It would indeed be easy to caricature it as sabotage. >> > Perhaps likewise the decision not to support network-mounted files > at IPL-time. But Mr. Blair is wont to deem such outcomes not as > affirmative decisions, but to assert that no such alternative was > ever given consideration; not so much asn unconscionable choice as > an unconscious one. > ----------------------------------------------<unsnip>------------------------------------------ I have to think that the cxomplexity of the code changes required would also mitigate angainst this changes as well. ----------------------------------------<snip>------------------------------------ The other notional deficiencies that have been cited here are, many of them, virtues; and the long list of PDS deficiencies that were addressed and largely removed for PDSEs, among them the radically deficient processing of PDS member aliases, has been passed over in silence. > I understand that when a PDS member name is removed by BLDL aliases > are not removed. Whether this is "radically deficient" depends in large > part on what happens when the remaining aliases are referenced or when > the PDS is compressed. I don't know. > > The decision might easily have been made in the opposite sense: Allow > members to have multiple equipotent names such that when any one is > removed any others remain effective, the space occupied by the member > being reclaimed only when the reference count is reduced to zero. > -----------------------------------------<unsnip>-------------------------------------------- I think you meant STOW, rather than BLDL. This business of not deleting the code until all the aliases are removed has been the same as the PDS ever since PDSE "hit the street. As long as a directlry entry still referes to the starting TTR of the emmber, it will be retained. Nothing I've read makes me believe that PDSE operates any differently. Nothing new or different here. And STOW only removes one name at a time. Rick ---------------------------------------------------------------------- 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 ---------------------------------------------------------------------- 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
