Re: Why is GRS ENQ needed in SMFDUMP program?

[Dale Miller]

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