Rick Fochtman said: > Peter, I suspect it's a carry-over from the days > when DISP=OLD did reserves on shared DASD. > I may be wrong.
Shmuel (Seymour J.) Metz said: | > I may be wrong. | You are. DADSM does a reserve. Various applications do RESERVE. But allocation does not. If that statement was referring to your previous sentence, then, as Shmuel said, you are wrong. However, if you were, instead, referring to (whether or not) "it's a carry-over," then I think you are right. Old habits (and expectations that are no longer valid) are hard to drop. DISP=OLD (itself) _never_ caused MVS Allocation (or any other MVS component) to do a RESERVE, period. If anything, DISP=OLD might have caused some code NOT to do a RESERVE, on the basis that the step had exclusive control of the data set, so one would not (by that logic) be needed. That of course ignores the shared DASD volume issue (in the absence of GRS, MIM, or a Sysplex) where a site has simple, de facto, shared DASD volumes. By that (incorrect) logic, a RESERVE would only be necessary when DISP=SHR was specified. But a RESERVE is, in fact, needed whenever certain entities are being accessed in any actual physical DASD sharing environment, regardless of DISP, but they can of course be converted to SYSTEMS ENQs if there is no physical sharing outside of the GRSplex/MIMplex). The linkage editor started doing SYSIEWLP/dsname RESERVEs eventually, but did so regardless of DISP=SHR|DISP=OLD. DADSM did a RESERVE on the volume from the very beginning of SHARED DASD device support during (some) VTOC update operations (but not all). The popular "last update date" mods/ZAPs to IFG0196W were totally dependent on the fact that the device was not RESERVEd at OPEN when the F1 DSCB is rewritten. CVAF takes care of this problem now, I understand. Few other OS components and utilities ever did any RESERVEs. But none did (or did not do) so based on the value of DISP= specified on any allocation. It would not have done any program any good to check specific allocations (DD statements) anyway, because the DD statement the program is using could have DISP=SHR, while another allocation (even one that is not in the current job step) might have DISP=OLD that would have caused the MVS Initiator to do an exclusive SYSDSN/dsname ENQ at JOB initiation. Many of us modified or front-ended various utility programs (such as IEBCOPY) to do a RESERVE (even sometimes when DISP=OLD was actually in effect), and then changed them when GRS first came out for "SP2" (that is, SP1.2, which never went G/A -- non-ESP sites got SP3, that is SP 1.3, first) to request convertible SYSTEMS RESERVE ENQs (all following the [I]SPF and IEWL precedents). Most shops I knew of had some form of these mods applied, so imagine my surprise when I encountered one that did not. These days, few shops seem to have anything like this. Go figure. We can speculate about why that is the case but we can speculate equally about why IBM has not (yet) stepped up to the plate to do what was, obviously as far back as 1983 [actually, in 1967, when the 2314 string switch became available and RESERVE and SHARED DASD device support was introduced]), and still is, needed. -- WB ---------------------------------------------------------------------- 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
