[Info-vax] Ken Coar's OpenVMS Lock utility sources are available on Sourceforge.

[Stephen Hoffman]

On 2020-11-06 23:12:17 +0000, Jon Pinkley said:

> I am showing my ignorance here, but how do you implement the equivalent 
> of waiting for a lock with a lock file (queuing a lock request, $ENQ)?  
> I can understand how the equivalent of lock/nowait/mode=exclusive could 
> be done with a lock file, but waiting?  It seems to me that would 
> involve polling.

Yeah, "polling is bad".  We're also operating on GHz-class processors.  
The performance concerns for checking something in a loop once a 
~second are negligible. Particularly if the DCL loop code is both 
simple and is never going to fast-loop. Premature optimization, etc. 
Put differently, I poll. It's simple, undemanding, with very low 
overhead at even an "aggressive" one-second polling loop, the resulting 
code is clear and easy to maintain and self-contained, and it works.

If I were polling more frequently or needed higher performance or 
faster responsiveness to changes, well, I probably also wouldn't be 
using DCL either.

As for alternatives, I've seen and have used both coordinated access 
with an indexed file (with records for tasks and PIDs and times) and 
that with polling from DCL to implement a "job scheduler", and have 
implemented a DECnet-based "job scheduler" from DCL.

As for what apps can do with files and what happens with source code 
that gets ported around, C offers file locking via fcntl et al.  On 
OpenVMS, that C locking support uses DLM.

And some other shells can have some locking analog, such as flock: 
https://linux.die.net/man/1/flock

I've seen and/or used scheduling tools such as Xgrid and distcc and 
ZooKeeper used for this on other platforms (and CMake and Ninja have 
capabilities here too), as well as job schedulers on OpenVMS including 
DECscheduler.

I'm skeptical of the value of incremental modifications to DCL given 
its oft-discussed limitations and issues. For various reasons. I would 
like prefer asynchronous capabilities in whatever might be the DCL 
upgrade path. Or in whatever might supplement DCL for scripting, if 
Python or Lua or some other scripting language might eventually ship in 
the base OS. DCL just doesn't do quadword math, or asynchronous I/O, or 
try-catch-punt error handling (yes, I know about ON and SET), or TLS, 
or a job scheduler, or... all that well. And I'd doubt that VSI would 
benefit from a DCL2 replacement or whatever as compared with the return 
on that investment. And that's ignoring what would traditionally then 
be a slow and messy and not-seamless migration from DCL to 
DCL2/zsh/whatever. Supplementing DCL with some other scripting tooling 
avoids most of that, without having to create a wholly new DCL-flavored 
domain-specific language and tooling. But then how quickly OpenVMS 
folks would adopt Python or Lua or whatever is itself an open question. 
So here we are...

Various of these smaller feature-related discussions are symptoms of 
larger missing features. This is one.


-- 
Pure Personal Opinion | HoffmanLabs LLC