[Info-vax] DCL, DLM, APIs, RAS, RuleWorks, etc

[Stephen Hoffman]

On 2022-10-28 00:32:28 +0000, Dave Froble said:

> On 10/27/2022 8:05 PM, Stephen Hoffman wrote:
>> 
>> Off the top...
>> 
>> Every peer process joining the peer group makes a call with some 
>> parameters, and each then gets a startup AST, and one peer process then 
>> gets the primary AST. Each joining process will initially get the 
>> startup AST, and will alway get the startup AST before the primary AST 
>> arrives. Any peer process may or may not get primary. The initial 
>> primary gets an uninitialized context block of 64 bytes (with an 
>> indication that the context is uninitialized/zeroed/invalid), and every 
>> subsequent process becoming primary gets the latest contents of that 
>> same context block. The primary can use that context block to request 
>> all peer processes perform a controlled exit (as they sequentially 
>> become primary) or whatever other means to communicate that, and/or can 
>> use the context block for passing around counters, and/or status, 
>> and/or whatever.
>> 
>> Basically, one call with an argument list containing the peer group 
>> name, two AST arguments, a context block, and maybe a context 
>> parameter. No itemlists. The call itself stalls or hibernates in user 
>> mode, waiting for something to happen.
>> 
> 
> And that is suppose to be better than what exists today?  I'm confused. 
>  That alone makes it worse.  Of course, I'm easily confused these days.

One call, with a peer group name, two AST routines specified for 
startup and for primary, a pointer to 64-byte structure, maybe a 
future-use flags pointer, and a return status value.

Don't need $enq calls and $enq lock conversion calls and the rest, 
don't need the itemlists, don't need to manage the lock promotions, nor 
the blocking or granting ASTs, nor the lock mode sequencing.

So... yes... simpler.

Can this all be implemented using $enq and ilk? Sure.

As for my increasing preference to avoid itemlists, I've become less 
fond of itemlists over the years, once having thought they were 
wonderful and flexible (and they were), but realizing the costs and 
issues with the whole design as I've used them, and this all 
particularly after having experienced some other API designs 
else-platform.  Also given there are inexplicably still no available 
OpenVMS APIs for processing itemlists within the called code, too. With 
the sorts of code and the limits envisioned when VAX/VMS got going, 
itemlists were and are great. But too many of the itemlist designs 
either get unwieldy with a call-to-size call first and then a 
call-to-call call second, or the calls get coded with limits that 
require breaking APIs. Or there are coding errors or latent security 
bugs lurking in the itemlist processing. But I digress.


-- 
Pure Personal Opinion | HoffmanLabs LLC