I see your point but I think the "conditionality" of a RESERVE macro 
applies only to the resource as defined by the qname/rname.  
Presumably, GRS solves this shortcoming.  
===


 
> Date: Mon, 25 Jun 2012 17:11:07 +0300
> From: bdis...@dissensoftware.com
> Subject: Re: Why is GRS ENQ needed in SMFDUMP program?
> To: IBM-MAIN@listserv.ua.edu
> 
> On Mon, 25 Jun 2012 09:44:08 -0400 J R <jayare...@hotmail.com> wrote:
> 
> :>The ENQ portion of the RESERVE macro goes ahead as usual.  
> :>The reserve bit in the UCB is only set if the ENQ is successful.  
> 
> :>The RESERVE macro implies IO to the device.  If there is no IO 
> :>before the subsequent DEQ, the hardware reserve doesn't need to be issued. 
> 
> My issue is that the I/O can be issued and be blocked because the device is
> reserved to another system. By issuing a conditional ENQ, one wishes an
> indication that the resource is not immediately available so that other
> actions can be taken.
> 
> If that is the way it works, so be it, but it seems wrong to me.
> 
> :>> Date: Mon, 25 Jun 2012 16:33:17 +0300
> :>> From: bdis...@dissensoftware.com
> :>> Subject: Re: Why is GRS ENQ needed in SMFDUMP program?
> :>> To: IBM-MAIN@listserv.ua.edu
> :>> 
> :>> On Mon, 25 Jun 2012 09:25:02 -0400 J R <jayare...@hotmail.com> wrote:
> :>> 
> :>> :>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.  
> :>> 
> :>> How would that work with a conditional reserve? How can the O/S know if 
> the
> :>> reserve can be satisfied unless the reserve I/O is complete?
> 
> --
> Binyamin Dissen <bdis...@dissensoftware.com>
> http://www.dissensoftware.com
> 
> Director, Dissen Software, Bar & Grill - Israel
> 
> 
> Should you use the mailblocks package and expect a response from me,
> you should preauthorize the dissensoftware.com domain.
> 
> I very rarely bother responding to challenge/response systems,
> especially those from irresponsible companies.
                                          
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Reply via email to