[Info-vax] inertia or fundamentals about langages?

[Stephen Hoffman]

TL;DR: Folks running production apps on ancient servers and versions 
are not a growing market. It might be a profitable market for some, but 
it's only going to shrink.  And vendors cannot support ancient versions 
forever. Not at the expense of new work.  End-users running these 
configurations will incur increasing costs.  Most will eventually break 
and drag their environments forward all protestations to the contrary.



On 2019-05-21 10:35:44 +0000, gérard Calliet said:

[[...extensive expurgation of erudition...]]   [[...also being the 
source of the unattributed quote...]]

> (1) understanding the parts of the software that need VMS,

There are certainly parts of apps that have platform dependencies, but 
there's comparatively little that's unique about OpenVMS in today's 
operating system market in terms of capabilities and features, much 
less what'll be unique in the market of five or ten years ahead.  Yes, 
comparatively little that's unique, but there are some OpenVMS features 
that are still fairly rare. The question for each ISV and for each 
installation is whether one or more of those unique features is 
sufficiently distinguishing.

Platforms might and variously do encourage apps to solve specific cases 
differently.  Sometimes very differently.

Specific app designs can and often do work better with some platforms 
than with others, too.  Which might mean changing app designs.

Hardware too changes, which can mean changing app designs.

> and the parts which would be better worked elsewhere,

A vendor is looking at where they need to improve and what of that 
which they want to focus and fund, and at where a product can be 
marketed and focused and further differentiated.

And at the trade-offs for the installed base, and for potential new 
customers.  These trade-offs tend to be pernicious over the longer-term.

An end-user or ISV is looking at the trade-offs between where a 
commercial operating system product is better, and where it's worse.

Whether an ISV can be sufficiently profitable, with apps built atop 
OpenVMS dependencies.

And at whether the better outweighs the worse, plus the cost and 
disruption and delay of the port.  And at the costs of maintaining the 
current practices and tooling and designs.

Better and worse in terms of features, tooling, APIs, available staff, 
vendor-specific and more general industry trends, vendor pricing risks, 
and other details.

Folks looking to justify an existing operating system choice, sure, 
this can be part of the preservation strategy.  Cost of porting off, 
too.

> which is to say understanding how the specifics of the use match the 
> specifics of VMS and central parts developed on it,

Porting an app or a design onto a platform looks at this, as does porting off.

Porting onto a platform also looks at the development tooling for the 
platform, at the app funding and schedules and plans, at the vendor and 
their funding and pricing and policies, at the risks of being beholden 
to the vendor, and at the market trends.

For many of the OpenVMS sites, the cheapest or lowest-risk answer is to 
keep paying for OpenVMS and for support and updates.  Inertia.  A local 
minima, if not a global minima.   OpenVMS does what they need, at a 
price they're willing top pay.

As for wholly new customers and wholly new app deployments?  That's a 
tougher sale.  The x86-64 port is one of many pieces on the way to 
improving that.

> (2) being able to "translate" the parts of the software that are 
> translatable, which is creating the "interfaces".

OpenVMS is a commercial product.  OpenVMS is a product that solves 
requirements that folks have and at a price folks are willing to pay.

If folks are not willing to pay enough, OpenVMS vanishes from the 
market, as have many other commercial operating system products, and as 
the communities and the preferences that built up around those other 
products then scatter.

For now, the installed base—and its inertia—is the VSI market.   In 
five or ten years, OpenVMS will have most or all of the same benefits, 
a few newer ones added, and a few detriments removed.  That'll keep 
much of the installed base around, and preferably with some new folks 
to offset the inevitable and insensible losses as existing apps are 
retired and replaced.

Never forget that OpenVMS is a commercial product, and that OpenVMS is 
a dependency for many of our apps.  That for both the end-users, and 
for the vendor, too.

ps: Folks at DEC were clearly pondering the effects of scale and 
commoditization of operating systems too, including with the 
much-maligned Windows NT Affinity marketing from the mid 1990s.  Those 
DEC folks were clearly right about the trend that Windows was on back 
then, too.  By then, the decisions that DEC had made around MICA were 
looking bad, too.   Look around underneath 
http://www.bitsavers.org/pdf/dec/prism/ for some perspectives and 
presentations from DEC in the late 1980s and early 1990s.

pps: Yes, there will always be those that don't or that defer and for 
whatever and variously good reasons http://ibm-1401.info/402.html and 
that can lead to headaches 
https://forrestbrown.co.uk/news/coboled-together-the-oldest-legacy-systems-still-in-use-today/ 


ppps: You're just starting to touch on some of the limitations of 
OpenVMS and its APIs and tooling in another of your postings here, with 
your quest for parsing and comparing time values.  Those API and 
tooling and documentation gaps are large and varied.  Old apps and old 
designs that will never be updated and for whatever reason? 
Configurations that are still running V5.5-2H4 and for whatever reason? 
 That might solve a problem that the end-customer has.  That'll keep a 
few vendors interested and some folks employed too, but it's most 
definitely not a market for VSI, and V5.5-2H4 is not a market that's 
going to increase in size.   Convincing those folks to move forward—and 
preferably providing those folks with that path forward for when their 
reasons for staying behind evaporate—is part of the VSI market for 
OpenVMS.  Eventually evolving enough effort intended to encourage 
experimental and new environments, too.  This is part of what VSI will 
be working on, past the completion of the x86-64 port.


-- 
Pure Personal Opinion | HoffmanLabs LLC