On 2017-06-12 20:15:51 +0000, Arne Vajh j said:
> Someone need to estimate the cost and the potential revenue.
>
> But I will recommend not being too fast to reject ideas.
>
> Especially not if the ideas are targeting a market that in general is
> relevant for VMS.
Sorry, no TR quote here. Just a code-slog.
Anybody that wants to can implement app restarts on OpenVMS. Right
now. For many environments, the effort involved is fussy and arcane.
There are many easy mistakes possible, too. But there's nothing here
that's particularly unique or unusual. Simplest approach starts with
the batch restart support that few use. SET RESTART_VALUE,
BATCH$RESTART, et al. More involved approaches can combine clustering
and shadowing, DEdtm distributed transaction manager, maybe RMS
journaling, or uses message queuing, or one of the previously-cited
frameworks. Inevitably distributed authentication and encryption.
Not that I'd consider any of these to be particularly modern
implementations for the developers to deal with.
Many developers ignore some or all of these available options.
Whether intentionally, or through omission or ignorance of the features
and capabilities, or they've been dissuaded by the license prices
involved?
From what's involved here in the layered products and in the OpenVMS
operating system, the integration, incorporation and further
abstraction of these existing features (and maybe adding something
equivalent to DECscheduler or HTcondor or another scheduler into the
mix) requires a decent investment in design and implementation in the
operating system, and it requires application modifications —
communications of state between the system and the apps, as well as
managing details such as distributed authentication and encryption, and
state change notifications — if this whole environment is to become
somewhat more transparent to the app developers. Some folks point to
the class scheduler, but in this context control groups (cgroups)
support provides rather more. For various folks, using a database for
this general purpose — online backups, recovery from failures,
restarting from some intermediate app state — works well enough.
Creating a simple and clear and easy-to-use design that integrate all
of these existing APIs and products — and whatever new giblets might be
added — is an order of magnitude harder, too.
Yet harder? Implementing something that's transparent to existing
apps is somewhere between a huge effort, an intractable effort, or
simply impossible. Not with all the app state baggage and network and
cluster baggage involved underneath all but the most trivial of OpenVMS
apps.
VSI mentions some semi-related research in this direction in their
roadmap (containers, et al), but there's still a lot of code to write
or port, and test and document and...
Just getting the whole development and APIs better documented —
including dragging the security manual forward by a quarter-century or
so — would be a start.