On Wed, 9 Dec 2015 15:25:11 -0500, Robert A. Rosenberg wrote: > > ... >There is however the issue of what type of ENQ to make for SYSDSN of >a PDS/PDSE. You need to issue a SHR while editing or the SPFEDIT is >useless. Note that for Non-PDS files you should be going SYSDSN/EXC >and no SPFEDIT is needed. > >As to why SPFEDIT is VOLSER-LESS I agree with you about the ISPF >person in error using SYSDSN's RNAME as a model. At this point in >time there is little that can be done to fix the situation. > Decades ago I was surprised to learn that I can allocate a new data set with only ENQ SHR, even while another job is holding ENQ SHR! Bad collateral damage, but no integrity violation.
And I just tried: With ISPF EDIT, I can cause secondary extent allocation *even*while*another*job*is*holding*SYSDSN*ENQ*SHR*! As far as I can conjecture, the only threat to integrity is when scratching an extent (presumably VTOC updates are already covered). So, an immodest proposal: o Allow the programmer to elect to use SYSDSN SHR instead of EXC. o When a DEB is created, allocation should obtain a new ENQ SHR Q=SYSEXTNT R=VOLSER+DSN+TTR (whatever unambiguously identifies the extent). o When an extent is scratched, that ENQ is momentarily upgraded to EXC. If that fails, ABEND; caveat emptor; shoulda used EXC in the first place. After the extent is freed, DEQ. o When a DEB is freed, as by CLOSE, DEQ. No extent can be scratched while it's otherwise in use; integrity is preserved. Years ago I proposed a similar scheme in this forum. An IBM employee pointed out that they sometimes manipulate data sets without DEBs; they need to use SYSDSN EXC. That's OK. It's what they're doing; they may continue to do so. -- gil ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
