On Wednesday, October 26, 2022 at 11:01:58 AM UTC-5, Single Stage to Orbit wrote:
> On Wed, 2022-10-26 at 17:01 +0200, hb wrote:
> > According to https://en.wikipedia.org/wiki/VAX_Common_Lisp, VAX LISP
> > was sold to Lucid Inc. There is a wikipedia article about Lucid. It
> > says that Lucid went bankrupt in 1994 and Lucid Common Lisp was sold.
> > VAX LISP isn't mentioned. Lucid Common Lisp ended up at LispWorks,
> > which sells it under their own name: Liquid Common Lisp.
> Interestingly enough LispWorks run on a deep space probe, rather
> successfully, I might add.
> --
> Tactical Nuclear Kittens

Someone did a fairly deep dive into using VAX Common Lisp:

https://netzhansa.blogspot.com/2018/08/evaluating-vax-lisp-30.html

It makes for some interesting reading.

On Wednesday, October 26, 2022 at 12:21:16 PM UTC-5, Robert Carleton wrote:
> On Wednesday, October 26, 2022 at 8:58:31 AM UTC-5, Arne Vajhøj wrote:
> > On 10/26/2022 6:44 AM, Robert Carleton wrote:
> > > So, who wound up with the intellectual property/source for VAX Common Lisp? Is it LispWorks Ltd?
> > I don't know Lisp so this may be a stupid question, but are there
> > any reason to believe DEC did not create VAX Lisp from scratch based
> > on language definition?
> >
> > If they did and they did not sell it off like Rdb and a few other
> > things, then IPR must have gone DEC->CPQ->HP->HPE and VSI
> > should have a license to use the source (the word here is
> > that VSI got license to everything VMS from HPE).
> >
> > Which will not help much as HPE has no interest in VMS any
> > longer and VSI will not see a business case for
> > migrating Lisp to Alpha/Itanium/x86-64.
> >
> > Arne
> My understanding is that VAX Common Lisp was created from Spice Lisp. Apparently, some of the DEC Lisp team came from CMU. I asked the LispWorks team if they have any stake in VAX Common Lisp. We'll see what they say.
>
> Cheers,
>
> --Bruce

According to a LispWorks representative, VAX Common Lisp wasn't passed down from Lucid. Apparently it's development stopped with Lucid. Well, if anyone knows where the source code landed, maybe it could be released under a public license and a cross-compilation could be attempted.

On 2022-10-25 13:12:39 +0000, Simon Clubley said:

> On 2022-10-24, Dave Froble <davef@tsoft-inc.com> wrote:
>> On 10/24/2022 6:06 PM, Robert Carleton wrote:
>>>
>>> Lisp implementations frequently have the ability to save an image of
>>> their state to disk. Coordinating one cluster node to save the image,
>>> then have a new process start on a different cluster node from the
>>> image should be possible. Is there a C API for DLM?
>>>
>>
>> VMS is not (hawk, spit, gag) C, and (hawk, spit, gag) C is not VMS
>>
>> There are a system services for using the DLM. Callable from ALL VMS
>> languages.
>> Even (hawk, spit, gag) C.
>>
>
> Not DCL however (at least as a part of VMS). That's a really big omission.

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.

Also showing OpenVMS development's longstanding proclivity for
flexibility over usability, combined with the avoidance of having
opinions, but I digress.

Doing a doorbell scheme is just stupidly complex with a whole lot of
user-written code, and the same for electing a primary process in a
cluster.

API support and documentation for creating cluster-aware and secure
networked apps is unfortunately lacking, too.

What is available is scattered around in the programming concepts and
networking manuals, and Y2K and newer is absolutely missing from the
security manuals, among other rough patches.

NB: I know how to do all of this. I've done this. All of it. I know the
APIs. I know the value. But wow, this stuff is just absurd to use.

And that's all before discussions approaching the addition of support
for app checkpoint-restart, whether that single host or cluster,
writing apps for clusters, or the utter lack of online backup sync, and
other software reliability-availability-scalability features.

And yes, the lack of DCL support for DLM, and the lack of DCL ssh and
sftp/scp, and the lack of SSH/TLS networking and authentication
generally, and a whole pile of other areas, is, well, lacking.

As for Lisp at DEC, that faded out with the DEC OPS-5 RuleWorks era,
and that's been available on the Freeware.
https://www.digiater.nl/openvms/freeware/v50/ruleworks/ Also see past
Lisp discussions here in the c.o.v. archives, too.

--
Pure Personal Opinion | HoffmanLabs LLC

In article <tj8nc7$20fgj$3@dont-email.me>, Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> writes:
>On 2022-10-24, Dave Froble <davef@tsoft-inc.com> wrote:
>> On 10/24/2022 6:06 PM, Robert Carleton wrote:
>>>
>>> Lisp implementations frequently have the ability to save an image of their state to disk. Coordinating one cluster node to save the image, then have a new process start on a different cluster node from the image should be possible. Is there a C API fo
>>>
>>
>> VMS is not (hawk, spit, gag) C, and (hawk, spit, gag) C is not VMS
>>
>> There are a system services for using the DLM. Callable from ALL VMS languages.
>> Even (hawk, spit, gag) C.
>>
>
>Not DCL however (at least as a part of VMS). That's a really big omission.

Why would you think you'd need DLM for a DCL procedure?

--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG

I speak to machines with the voice of humanity.

On 2022-10-27 20:19:50 +0000, VAXman- @SendSpamHere.ORG said:

> In article <tj8nc7$20fgj$3@dont-email.me>, Simon Clubley
> <clubley@remove_me.eisner.decus.org-Earth.UFP> writes:
>>
>> Not DCL however (at least as a part of VMS). That's a really big omission.
>
> Why would you think you'd need DLM for a DCL procedure?

As with many of us, I have distributed DCL running in a cluster.

I'd rather not have to create local code for the cluster coordination
tasks, or create my own DCL interface into DLM. Code which I have
already created. As likely have others.

Batch and server queues are insufficient for the coordination needs
absent queue configuration efforts ranging somewhere between heroic and
problematic, or without coding and running my own server symbiont.

Using turd files for coordination gets gnarly, too.

Other DCL omissions include ssh/sftp/scp support, TLS, LDAP, etc. All
of which and much more have been discussed previously.

--
Pure Personal Opinion | HoffmanLabs LLC

On 10/27/2022 2:03 PM, Stephen Hoffman wrote:
> On 2022-10-25 13:12:39 +0000, Simon Clubley said:
>
>> On 2022-10-24, Dave Froble <davef@tsoft-inc.com> wrote:
>>> On 10/24/2022 6:06 PM, Robert Carleton wrote:
>>>>
>>>> Lisp implementations frequently have the ability to save an image of their
>>>> state to disk. Coordinating one cluster node to save the image, then have a
>>>> new process start on a different cluster node from the image should be
>>>> possible. Is there a C API for DLM?
>>>>
>>>
>>> VMS is not (hawk, spit, gag) C, and (hawk, spit, gag) C is not VMS
>>>
>>> There are a system services for using the DLM. Callable from ALL VMS languages.
>>> Even (hawk, spit, gag) C.
>>>
>>
>> Not DCL however (at least as a part of VMS). That's a really big omission.
>
> 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.

> 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 ...

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

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

On 10/27/2022 7:18 PM, Arne Vajhøj wrote:
> On 10/27/2022 5:20 PM, Dave Froble wrote:
>> 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.

> 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()

Locking is a common feature in distributed caches.

But they are often even simpler than above.

Hazelcast:

ILock lck = client.getLock(resnam);
lck.lock();
....
lck.unlock();

Apache Ignite:

Lock lck = cache.getLock(resnam);
lck.lock();
....
lck.unlock();

Arne

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:
>>> 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.

And it is also worth noting that when Linux copied the
DLM concept then they kept the API pretty similar to VMS:

https://linux.die.net/man/3/dlm_lock

Arne

On 2022-10-27 21:20:50 +0000, Dave Froble said:

> 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.

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.

--
Pure Personal Opinion | HoffmanLabs LLC

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@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

On 10/27/2022 8:05 PM, Stephen Hoffman wrote:
> On 2022-10-27 21:20:50 +0000, Dave Froble said:
>
>> 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.
>
>
> 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.

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

On 10/27/2022 8:30 PM, Dave Froble wrote:
> On 10/27/2022 7:18 PM, Arne Vajhøj wrote:
>> 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.

> 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.

The traditional lock model is that:
* locks are just identifiable with no implied semantics
* the applications acquire and release (lock and unlock)
* the lock manager just administer locks it does not
actually block anything so applications need to be cooperative

In that model the identifier could be a name or a number.
A name is a superset of number, so it sort of makes sense.

Numeric ranges is different. Well if 0-100 is just an id
like "0-100" then it fits above. But if there are
semantics like a lock on 0-100 actually blocks
a lock on 50-150 then it is a totally different model.

Arne

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

On Wednesday, October 26, 2022 at 12:21:58 PM UTC-5, Robert Carleton wrote:
> On Wednesday, October 26, 2022 at 11:01:58 AM UTC-5, Single Stage to Orbit wrote:
> > On Wed, 2022-10-26 at 17:01 +0200, hb wrote:
> > > According to https://en.wikipedia.org/wiki/VAX_Common_Lisp, VAX LISP
> > > was sold to Lucid Inc. There is a wikipedia article about Lucid. It
> > > says that Lucid went bankrupt in 1994 and Lucid Common Lisp was sold.
> > > VAX LISP isn't mentioned. Lucid Common Lisp ended up at LispWorks,
> > > which sells it under their own name: Liquid Common Lisp.
> > Interestingly enough LispWorks run on a deep space probe, rather
> > successfully, I might add.
> > --
> > Tactical Nuclear Kittens
> Someone did a fairly deep dive into using VAX Common Lisp:
>
> https://netzhansa.blogspot.com/2018/08/evaluating-vax-lisp-30.html
>
> It makes for some interesting reading.

It turns out that a video of Hans Hübner's quest was made:

https://player.vimeo.com/video/341012525

It's an interesting story. From his research, it sounds like the source may be too far out of reach for now. Maybe someday.