[Info-vax] DCL, DLM, APIs, RAS, RuleWorks, etc
Arne Vajhøj
arne at vajhoej.dk
Thu Oct 27 19:18:16 EDT 2022
- Previous message (by thread): [Info-vax] DCL, DLM, APIs, RAS, RuleWorks, etc
- Next message (by thread): [Info-vax] DCL, DLM, APIs, RAS, RuleWorks, etc
- Messages sorted by:
[ date ]
[ thread ]
[ subject ]
[ author ]
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
- Previous message (by thread): [Info-vax] DCL, DLM, APIs, RAS, RuleWorks, etc
- Next message (by thread): [Info-vax] DCL, DLM, APIs, RAS, RuleWorks, etc
- Messages sorted by:
[ date ]
[ thread ]
[ subject ]
[ author ]
More information about the Info-vax
mailing list