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

[Dave Froble]

On 10/27/2022 7:18 PM, Arne Vajhøj wrote:
> On 10/27/2022 5:20 PM, Dave Froble wrote:
>> On 10/27/2022 2:03 PM, Stephen Hoffman wrote:
>>> The DLM API was and remains a nice box of parts arising from the 1980s, and does
>>> still work and does work well, but the API is really showing its age.
>>
>> Good ideas can have a length lifespan.
>>
>> But I confess to curiosity, what would a better API for the DLM look like?
>> I've used it from Basic, and anything one can use from Basic has got to be
>> rather simple.
>
> Suggestions for best API is like suggestions for best programming
> language or best editor.
>
> :-)
>
> I have no idea what Hoff want.
>
> But if you want my take, then I think below would be good for 98% of cases.
>
> Procedural:
>
> lckid = lib$enqw(resnam, lockmode, flags)
> ...
> lib$deq(lckid)
>
> OO:
>
> lck = new Lock(resnam, flags)
> lck.get(lockmode)
> ...
> lck.release()
>
> Obviously something additional would be required for the 2% with
> advanced requirements for async, but there are newer ways to
> do async as well.
>
>>> Also showing OpenVMS development's longstanding proclivity for flexibility over
>>> usability, combined with the avoidance of having opinions, but I digress.
>>
>> Three cheers for flexibility ...
>
> Itemlists are not that bad. Sometimes the flexibility is really nice.
>
> API's with itemlists just tend to come with a learning curve.
>
> Arne
>
>

Your biggest problem is that you're still thinking of a resource name.  I think 
it would be trivial to add multiple lock types, with no specification defaulting 
to resource name, and a second type would be a numeric range.  As for a third, I 
have no idea, at this time.

-- 
David Froble                       Tel: 724-529-0450
Dave Froble Enterprises, Inc.      E-Mail: davef at tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA  15486