The RESERVE macro did (still does?) not directly do the hardware reserve. Rather, it set a bit in the UCB to tell the next IO to the unit to prepend a reserve CCW to the channel program. ===
> Date: Mon, 25 Jun 2012 15:10:48 +0200 > From: [email protected] > Subject: SV: Why is GRS ENQ needed in SMFDUMP program? > To: [email protected] > > 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:[email protected]] > > För Dale Miller > > Skickat: den 25 juni 2012 12:34 > > Till: [email protected] > > Ä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 [email protected] with the message: INFO IBM-MAIN
