Are You implying that the RESERVE macro did a hardware RESERVE "under the covers" ?
Regards, Thomas Berg _______________________________________________________ Thomas Berg Specialist AM/SM&S SWEDBANK AB (publ) > -----Ursprungligt meddelande----- > Från: IBM Mainframe Discussion List [mailto:IBM-MAIN@listserv.ua.edu] > För Dale Miller > Skickat: den 25 juni 2012 12:34 > Till: IBM-MAIN@listserv.ua.edu > Ämne: Re: Why is GRS ENQ needed in SMFDUMP program? > > You might call the RESERVE macro a special form of ENQ, but the actual > reserve was a hardware feature on DASD. When a reserve was initiated > by a processor, I/O's from other processors were delayed until the > reserve was released. The use of the ENQ was (IIRC) to provide a finer- > grained interlock between processes running on the same processor. > Nearly 30 years ago (before LPAR's and SYSPLEXes),I was a systems > programmer at one installation where we had lots of 3344 dasd units > and were running DOS'es under VM. We did a very successful migration > to 2 MVS's with no DOS and no VM. However, it we were plagued with > reserve lockouts until we found the problems. > The first issue was VM's asinine treatment of reserves - we had a > choice of configuring VM to either: (1) pass the reserve on to the > disk physically, which provided lockout from I/O by another physical > processor but did not distinguish between different guests, or (2) to > handle the reserves logically (internal to VM) which successfully > interlocked guests on the same processor, but did not do the hardware > reserve, so there was no interlock between processors. That issue was > resolved when we dumped the DOS'es and VM and ran a test and a > production MVS on different machines. > However, we still had reserve lockouts from time to time. It turns out > that the 3340's were configured (as advertised) as 4 3340's each, and > defined in MVS as 4 units. However, it turned out that there was only > one reserve register (?) per 3344, so a reserve against one of the > logical units effectively reserved all 4, and MVS did not recognize > the situation. This was ameliorated by careful dataset placement, but > was finally resolved when we went to 3350's. I complained about this > to the local IBM staff, but I'm not sure they believed me, and > software support was done by FE's, so I'm not sure the situation was > ever fixed, or even APAR'ed. > > > Dale Miller > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
