Marc Van Dyck schrieb am 29.01.2024 um 16:36:
> Dave Froble formulated the question :
>> On 1/28/2024 8:32 AM, Arne Vajhøj wrote:
>>> On 1/28/2024 8:25 AM, Marc Van Dyck wrote:
>>>> Simon Clubley formulated the question :
>>>>> Does anyone have any others to add to the list ?
>>>>
>>>> Yes. Some kind of automatic disaster recovery. That is, if a process,
>>>> or a set of processes, run on a system that crashes, those processes
>>>> are
>>>> automatically restarted on another cluster member, transparently, with
>>>> no manual intervention, and continue from the point they were at when
>>>> the system crashed. No transaction lost of any kind, and without having
>>>> to add anything in the code that those processes are running. The
>>>> operating system (or layered product) does all the work transparently.
>>>> Should work with code written 30 years ago, with ACMS applications,
>>>> anything.
>>>
>>> Something like Tandem NonStop lock-step?
>>>
>>> Arne
>>>
>>>
>>
>> Well, no, not really.  What I'd envision would be what I'd call an
>> application monitor, for lack of a better name, that would be able to
>> know what the applications should be doing, to monitor that activity,
>> and to do whatever necessary to continue the activity, should anything
>> happen to that activity. Yeah, non-stop, but not the Tandem design.
>>
>> Just a concept, and design and implementation might be "interesting".
>>
>> I'd just note that the OSs would be included as applications, so
>> re-starting them from where they were interrupted would be included in
>> the concept.  So, yeah, the monitor would be outside/over the OSs.
>> Perhaps something like happens with VMs.  Except VMs want to move the
>> activity to another system, not recover on the same system.
>
> Whatever the design and implementation, this would be a really useful
> and marketable addition to the OpenVMS cluster concept. Clusters were
> invented 40 years ago to implement horizontal scalability, because
> vertical scalability was impossible, technically or financially. This
> issue has mostly disappeared today, current hardware being able to
> deliver any power we might want. Today's clusters are essentially
> put in place for redundancy or disaster recovery purposes ; the next
> logical step should be to provide this redundancy in a transparent way
> to the system user.
>
> This should also be, as opposed to simple user niceties, something that
> allows VSi to make money with.

Would OpenVMS Service Control cover your needs?

<https://vmssoftware.com/products/service-control/>

Service Control was originally developed by Wolfgang Burger at HP in
Vienna and later adopted by VSI. As far as I know it is (still) offered
as a service, not a product - but only VSI can tell.

Hans.

On 1/29/2024 6:21 PM, Hans Bachner wrote:
> Marc Van Dyck schrieb am 29.01.2024 um 16:36:
>> Dave Froble formulated the question :
>>> I'd just note that the OSs would be included as applications, so
>>> re-starting them from where they were interrupted would be included
>>> in the concept.  So, yeah, the monitor would be outside/over the OSs.
>>> Perhaps something like happens with VMs.  Except VMs want to move the
>>> activity to another system, not recover on the same system.
>>
>> Whatever the design and implementation, this would be a really useful
>> and marketable addition to the OpenVMS cluster concept. Clusters were
>> invented 40 years ago to implement horizontal scalability, because
>> vertical scalability was impossible, technically or financially. This
>> issue has mostly disappeared today, current hardware being able to
>> deliver any power we might want. Today's clusters are essentially
>> put in place for redundancy or disaster recovery purposes ; the next
>> logical step should be to provide this redundancy in a transparent way
>> to the system user.
>>
>> This should also be, as opposed to simple user niceties, something that
>> allows VSi to make money with.
>
> Would OpenVMS Service Control cover your needs?
>
> <https://vmssoftware.com/products/service-control/>
>
> Service Control was originally developed by Wolfgang Burger at HP in
> Vienna and later adopted by VSI. As far as I know it is (still) offered
> as a service, not a product - but only VSI can tell.

This indeed seems like the app<--->VMS equivalent of
VM<--->ESXi.

You define an app to be running on one node in the cluster
and if something happens then the software start the app
on another node.

Like you define a VM to be running on one ESXi server in the
cluster and if something happens then VMWare spin up
the VM on another ESXi server.

Arne

On 1/29/2024 7:00 PM, Arne Vajhøj wrote:
> On 1/29/2024 6:21 PM, Hans Bachner wrote:
>> Marc Van Dyck schrieb am 29.01.2024 um 16:36:
>>> Dave Froble formulated the question :
>>>> I'd just note that the OSs would be included as applications, so re-starting
>>>> them from where they were interrupted would be included in the concept. So,
>>>> yeah, the monitor would be outside/over the OSs. Perhaps something like
>>>> happens with VMs. Except VMs want to move the activity to another system,
>>>> not recover on the same system.
>>>
>>> Whatever the design and implementation, this would be a really useful
>>> and marketable addition to the OpenVMS cluster concept. Clusters were
>>> invented 40 years ago to implement horizontal scalability, because
>>> vertical scalability was impossible, technically or financially. This
>>> issue has mostly disappeared today, current hardware being able to
>>> deliver any power we might want. Today's clusters are essentially
>>> put in place for redundancy or disaster recovery purposes ; the next
>>> logical step should be to provide this redundancy in a transparent way
>>> to the system user.
>>>
>>> This should also be, as opposed to simple user niceties, something that
>>> allows VSi to make money with.
>>
>> Would OpenVMS Service Control cover your needs?
>>
>> <https://vmssoftware.com/products/service-control/>
>>
>> Service Control was originally developed by Wolfgang Burger at HP in Vienna
>> and later adopted by VSI. As far as I know it is (still) offered as a service,
>> not a product - but only VSI can tell.
>
> This indeed seems like the app<--->VMS equivalent of
> VM<--->ESXi.
>
> You define an app to be running on one node in the cluster
> and if something happens then the software start the app
> on another node.
>
> Like you define a VM to be running on one ESXi server in the
> cluster and if something happens then VMWare spin up
> the VM on another ESXi server.
>
> Arne

Well, there are apps, and then there are other apps ...

Ok, a web server handling connection requests. Perhaps one or more connections
are disrupted before finishing. A re-start will begin to again handle
connection requests. Perhaps reasonable.

Then, an example from one of my old customers:

Orders were build interactively, and the data was stored in an intermediate
file. When done building, the intermediate file is then queued to a poster that
processes the data and performs updates to all pertinent database files, then
deletes the intermediate file.

Ok, what happens when the system crashes during processing of an order? Things
are left incomplete and a nasty mess. Re-starting the poster will make things
worse. So, just restarting is not such a good idea.

In the example, best not to process the order that was interrupted. Thankfully,
this almost never happened. Thank you VMS and DEC hardware and battery backup
UPS. But, it was still a possibility.

The partial solution was to build checkpoints into the design. At each specific
point in the poster, a flag was set, and forced to disk, as each file update
occurred. The poster was set up to respect the checkpoint flags. Worked sort
of well. Thee was still the possibility the checkpoint flags weren't written to
disk. I didn't have an app that reviewed the information, and automatically
re-queued it telling the poster where to re-start. That was a tedious manual task.

Hey, with most things, there is a point of diminishing returns on efforts. Just
not worth the cost.

Please don't start ranting about a database with 2 stage commits. Didn't have one.

But my point is, just re-starting an application isn't always a solution.

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

Dave Froble wrote on 30/01/2024 :
> On 1/29/2024 7:00 PM, Arne Vajhøj wrote:
>> On 1/29/2024 6:21 PM, Hans Bachner wrote:
>>> Marc Van Dyck schrieb am 29.01.2024 um 16:36:
>>>> Dave Froble formulated the question :
>>>>> I'd just note that the OSs would be included as applications, so
>>>>> re-starting
>>>>> them from where they were interrupted would be included in the concept.
>>>>> So,
>>>>> yeah, the monitor would be outside/over the OSs. Perhaps something like
>>>>> happens with VMs. Except VMs want to move the activity to another
>>>>> system,
>>>>> not recover on the same system.
>>>>
>>>> Whatever the design and implementation, this would be a really useful
>>>> and marketable addition to the OpenVMS cluster concept. Clusters were
>>>> invented 40 years ago to implement horizontal scalability, because
>>>> vertical scalability was impossible, technically or financially. This
>>>> issue has mostly disappeared today, current hardware being able to
>>>> deliver any power we might want. Today's clusters are essentially
>>>> put in place for redundancy or disaster recovery purposes ; the next
>>>> logical step should be to provide this redundancy in a transparent way
>>>> to the system user.
>>>>
>>>> This should also be, as opposed to simple user niceties, something that
>>>> allows VSi to make money with.
>>>
>>> Would OpenVMS Service Control cover your needs?
>>>
>>> <https://vmssoftware.com/products/service-control/>
>>>
>>> Service Control was originally developed by Wolfgang Burger at HP in
>>> Vienna
>>> and later adopted by VSI. As far as I know it is (still) offered as a
>>> service,
>>> not a product - but only VSI can tell.
>>
>> This indeed seems like the app<--->VMS equivalent of
>> VM<--->ESXi.
>>
>> You define an app to be running on one node in the cluster
>> and if something happens then the software start the app
>> on another node.
>>
>> Like you define a VM to be running on one ESXi server in the
>> cluster and if something happens then VMWare spin up
>> the VM on another ESXi server.
>>
>> Arne
>
> Well, there are apps, and then there are other apps ...
>
> Ok, a web server handling connection requests. Perhaps one or more
> connections are disrupted before finishing. A re-start will begin to again
> handle connection requests. Perhaps reasonable.
>
> Then, an example from one of my old customers:
>
> Orders were build interactively, and the data was stored in an intermediate
> file. When done building, the intermediate file is then queued to a poster
> that processes the data and performs updates to all pertinent database files,
> then deletes the intermediate file.
>
> Ok, what happens when the system crashes during processing of an order?
> Things are left incomplete and a nasty mess. Re-starting the poster will
> make things worse. So, just restarting is not such a good idea.
>
> In the example, best not to process the order that was interrupted.
> Thankfully, this almost never happened. Thank you VMS and DEC hardware and
> battery backup UPS. But, it was still a possibility.
>
> The partial solution was to build checkpoints into the design. At each
> specific point in the poster, a flag was set, and forced to disk, as each
> file update occurred. The poster was set up to respect the checkpoint flags.
> Worked sort of well. Thee was still the possibility the checkpoint flags
> weren't written to disk. I didn't have an app that reviewed the information,
> and automatically re-queued it telling the poster where to re-start. That
> was a tedious manual task.
>
> Hey, with most things, there is a point of diminishing returns on efforts.
> Just not worth the cost.
>
> Please don't start ranting about a database with 2 stage commits. Didn't
> have one.
>
> But my point is, just re-starting an application isn't always a solution.

No, just restarting isn't the solution. And engineering the application
to support random restarts isn't either. Just select a process from a
system window, drag and drop it in another system window, and it
continues to run on the other system as if nothing happened. That's
what
I'm after...

--
Marc Van Dyck

On Thu, 25 Jan 2024 13:21:38 -0000 (UTC)
Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:

> On 2024-01-24, Dave Froble <davef@tsoft-inc.com> wrote:
> > On 1/24/2024 8:13 AM, Simon Clubley wrote:
> >> On 2024-01-23, Dave Froble <davef@tsoft-inc.com> wrote:
> >>>
> >>> What is really rude is talking about Linux on c.o.v ...
> >>>
> >>
> >> Unless you consider VMS to be perfect and not in need of any
> >> improvement, other operating systems offer some good ideas that it
> >> would be nice to see in VMS, especially around security and
> >> internal isolation in general.
> >
> > Then discuss the ideas and concepts ...
> >
>
> OK.
>
> A random sample of things from Linux/Unix I would like to see in VMS:
>
> Mandatory Access Controls (my preference) or jails (Stephen's
> preference).
>
> A shell with decent modern functionality such as:
>
> Proper command history retention and merging from multiple
> sessions Easy searching of command history
> Tab completion
> Editing long command lines
> Globbing
>
> Proper package management and management of updates.
>
> Loadable and unloadable kernel modules, with device
> driver/filesystem/etc functionality available from within these
> modules.
>
> ASLR and KASLR support.
>
> Proper timezone management. (Everything is always UTC based, and your
> timezone is merely a local session property with no effect on the
> on-disk timestamps).
>
> The last one is policy-based, not technical:
>
> A vendor that has proper security reporting mechanisms.
>
> Does anyone have any others to add to the list ?
>
> Simon.
>

RDP ?

On 1/30/2024 5:20 AM, Marc Van Dyck wrote:
> Dave Froble wrote on 30/01/2024 :
>> Ok, a web server handling connection requests.  Perhaps one or more
>> connections are disrupted before finishing.  A re-start will begin to
>> again handle connection requests.  Perhaps reasonable.
>>
>> Then, an example from one of my old customers:
>>
>> Orders were build interactively, and the data was stored in an
>> intermediate file.  When done building, the intermediate file is then
>> queued to a poster that processes the data and performs updates to all
>> pertinent database files, then deletes the intermediate file.
>>
>> Ok, what happens when the system crashes during processing of an
>> order? Things are left incomplete and a nasty mess.  Re-starting the
>> poster will make things worse.  So, just restarting is not such a good
>> idea.
>>
>> In the example, best not to process the order that was interrupted.
>> Thankfully, this almost never happened.  Thank you VMS and DEC
>> hardware and battery backup UPS.  But, it was still a possibility.
>>
>> The partial solution was to build checkpoints into the design.  At
>> each specific point in the poster, a flag was set, and forced to disk,
>> as each file update occurred.  The poster was set up to respect the
>> checkpoint flags.  Worked sort of well.  Thee was still the
>> possibility the checkpoint flags weren't written to disk.  I didn't
>> have an app that reviewed the information, and automatically re-queued
>> it telling the poster where to re-start.  That was a tedious manual task.
>>
>> Hey, with most things, there is a point of diminishing returns on
>> efforts. Just not worth the cost.
>>
>> Please don't start ranting about a database with 2 stage commits.
>> Didn't have one.
>>
>> But my point is, just re-starting an application isn't always a solution.
>
> No, just restarting isn't the solution. And engineering the application
> to support random restarts isn't either. Just select a process from a
> system window, drag and drop it in another system window, and it
> continues to run on the other system as if nothing happened. That's what
> I'm after...

There are different models for HA:
A) application managed - the application store state somewhere where
a new instance can pick it up - this is not that hard to implement
but the application need to be written for it
B) system managed - the system store state somewhere where
a new instance can pick it up - this is hard to implement
but the application doesn't need to be written for it
A2) same as A with a feature where the system can move the application
from one node to another node - don't schedule the
processes/threads, copy memory content to other node, get various
files/network connections opened on the other node, schedule the
processes/threads on the new node, kill the instance on the
old node - harder than A but easier than B

Arne

On 1/30/2024 7:05 PM, Arne Vajhøj wrote:
> On 1/30/2024 5:20 AM, Marc Van Dyck wrote:
>> Dave Froble wrote on 30/01/2024 :
>>> Ok, a web server handling connection requests. Perhaps one or more
>>> connections are disrupted before finishing. A re-start will begin to again
>>> handle connection requests. Perhaps reasonable.
>>>
>>> Then, an example from one of my old customers:
>>>
>>> Orders were build interactively, and the data was stored in an intermediate
>>> file. When done building, the intermediate file is then queued to a poster
>>> that processes the data and performs updates to all pertinent database files,
>>> then deletes the intermediate file.
>>>
>>> Ok, what happens when the system crashes during processing of an order?
>>> Things are left incomplete and a nasty mess. Re-starting the poster will
>>> make things worse. So, just restarting is not such a good idea.
>>>
>>> In the example, best not to process the order that was interrupted.
>>> Thankfully, this almost never happened. Thank you VMS and DEC hardware and
>>> battery backup UPS. But, it was still a possibility.
>>>
>>> The partial solution was to build checkpoints into the design. At each
>>> specific point in the poster, a flag was set, and forced to disk, as each
>>> file update occurred. The poster was set up to respect the checkpoint flags.
>>> Worked sort of well. Thee was still the possibility the checkpoint flags
>>> weren't written to disk. I didn't have an app that reviewed the information,
>>> and automatically re-queued it telling the poster where to re-start. That
>>> was a tedious manual task.
>>>
>>> Hey, with most things, there is a point of diminishing returns on efforts.
>>> Just not worth the cost.
>>>
>>> Please don't start ranting about a database with 2 stage commits. Didn't
>>> have one.
>>>
>>> But my point is, just re-starting an application isn't always a solution.
>>
>> No, just restarting isn't the solution. And engineering the application
>> to support random restarts isn't either. Just select a process from a
>> system window, drag and drop it in another system window, and it
>> continues to run on the other system as if nothing happened. That's what
>> I'm after...
>
> There are different models for HA:
> A) application managed - the application store state somewhere where
> a new instance can pick it up - this is not that hard to implement
> but the application need to be written for it
> B) system managed - the system store state somewhere where
> a new instance can pick it up - this is hard to implement
> but the application doesn't need to be written for it
> A2) same as A with a feature where the system can move the application
> from one node to another node - don't schedule the
> processes/threads, copy memory content to other node, get various
> files/network connections opened on the other node, schedule the
> processes/threads on the new node, kill the instance on the
> old node - harder than A but easier than B

"B" is what I had in mind in my earlier post.

But, what will the customers pay for?

In the example I posted earlier, I didn't get paid for the checkpointing work.
Customer didn't care about little glitches. It offended my sensibilities
concerning "right and wrong". After I thought about the solution, I just
implemented it, for my own satisfaction. I felt much better.

:-)

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