I have to side with William on this one, the DISP in JCL refers to the dataset, not a member, and if DISP did work the way you describe, I would find it to be counter-intuitive. When I have had users make this mistake, I have always looked at them rather incredulously - I have a hard time understanding why one would think that the scope of DISP would change based on whether a member name is coded - that just does not make sense to me. I guess it goes without saying, that I have never made this particular mistake. I have, of course, made numerous other mistakes, just not this one.
>>> Paul Gilmartin <[email protected]> 8/2/2010 4:13 PM >>> On Mon, 2 Aug 2010 14:38:08 -0500, William H. Blair wrote: > >For there to have been a "rationale" (for a decision or choice) >there would have to have been a decision or choice (not to call >STOW to delete the member). There never was such a decision made >so there was (and is) no need to justify something that never, >in fact, happened. > >> Nowadays the only rationale, spurious, is that "it's always >> been that way." And ever shall be, as long as descendants of >> OS/360 endure. > >Nope. There is [still] no "rationale" because there has never >been any consideration of the issue -- serious or otherwise. > Mentally reviewing this thread, I recall considerable sentiment (not necessarily majority) that when the user cites a member when allocating with a DELETE disposition, the reasonable expectation is that the entity to be deleted is the member mentioned. I see "never been any consideration" as a failure of the designers to step back and ask themselves, "What will be the customers' perception of this behavior?" The resource deficiency, then, appears to have been in the designers' perspective. Considering options and selecting one based on a cost/ benefit analysis is more laudable than approaching the problem with tunnel vision and failing to consider other options than one. -- gil ---------------------------------------------------------------------- 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 CONFIDENTIALITY/EMAIL NOTICE: The material in this transmission contains confidential and privileged information intended only for the addressee. If you are not the intended recipient, please be advised that you have received this material in error and that any forwarding, copying, printing, distribution, use or disclosure of the material is strictly prohibited. If you have received this material in error, please (i) do not read it, (ii) reply to the sender that you received the message in error, and (iii) erase or destroy the material. Emails are not secure and can be intercepted, amended, lost or destroyed, or contain viruses. You are deemed to have accepted these risks if you communicate with us by email. Thank you. ---------------------------------------------------------------------- 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
