On Wed, 28 Jul 2010 10:04:52 -0400, Thompson, Steve wrote: > ><SNIP> >If you don't understand what's wrong with PDS, re-read Etienne Thijsse's >thread on attempting to delete a PDSE member. Or imagine my astonished >dismay the first time I allocated a member with DISP=(OLD,DELETE) and >watched the entire PDS vanish. Enough counterintuitive behaviors and >"flaws" >with recondite repairs add up to "wrong". > ><SNIPPAGE> > >I suppose that if I were to work with a VSAM file with >DISP=(SHR,DELETE), that it would be JCL's fault when the VSAM file goes >to the bit bucket. > >And if you were using a data base that you have to point to, and you >wanted to delete a row and coded DISP=(OLD,DELETE), that would be JCL's >fault also. > What are you assuming appears as the value of DSN=? (I'm not sure what you mean by a VSAM file?) I'd expect a JCL error for "(SHR,DELETE)" since exclusive access is required for DELETE.
In the second case, if DSN= identifies a particular row (is this syntactically possible?), I'd intuitively expect that one row to be deleted; if DSN= identifies the entire data base, the entire data base should be deleted. We are burdened nowadays with Byzantine behaviors that were a necessary accommodation to resource constraints that prevailed 45 years ago. Today, if the programmer codes DSN=DATA.SET(MEMBER), DISP=(OLD,DELETE), it should be easy enough for deallocation to issue a STOW to delete that specific member. The PDS itself is an accommodation to such an antiquated constraint. In 1965 it was elegant; nowadays it's a quaint PITA. -- gil ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
