[Info-vax] Where to locate software

[johnwallace4 at yahoo.co.uk]

On Saturday, 11 June 2016 18:44:23 UTC+1, Stephen Hoffman  wrote:
> On 2016-06-11 01:59:44 +0000, Kerry Main said:
> 
> > Re: pricing- agree that current pricing strategies is an issue that 
> > needs to  be addressed at some future point.
> 
> Everything you're pointing to here — all of it — is an added cost, an 
> added expense, and requires added and often platform-unique skills.
> 
> Yes, those are needed for any platform — to a degree — the difference 
> being that users are going to be less interested in new deployments and 
> new applications on OpenVMS in the absence of those skills.
> 
> OpenVMS must get simpler.   OpenVMS must become easier to use, easier 
> to manage, easier to deploy, easier to integrate, and it must become 
> more secure and more affordable and easier to develop.
> 
> Which gets back to details like there being NO DOCUMENTATION ON HOW TO 
> BUILD AND DEPLOY SOFTWARE ON THE PLATFORM.   Sure, keep avoiding that 
> slight detail.   What kicked off this thread.
> 
> Want OpenVMS to succeed?  First and foremost, VSI has to make enough 
> revenue, and — for the foreseeable future — that's only coming from the 
> installed base.
> 
> If OpenVMS is to continue past the end of the installed base and the 
> retirement of various of the existing applications, then new 
> deployments and new applications are a requirement.   What are factors 
> involved with maintaining and growing the base?  Sure, purchase costs 
> are a factor.   But as more than a few folks around here are fond of 
> referencing, TCO is (hopefully) involved in the discussions.    Well, 
> guess what?    What we are discussing here is TCO, and where OpenVMS 
> can get better, and where it must get better.   Having documentation 
> and tools for developers?   For sustainable, secure, upgradable and 
> "container-able" / "app stackable" and "app removable" and 
> rolling-upgradable applications?   About how fast new TLS deployments 
> can happen, or fixes for some other security bug in OpenVMS or an LP?   
> (Because those aren't going to happen any less often, or need to happen 
> any more slowly.  But I digress.)    All part of TCO.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> -- 
> Pure Personal Opinion | HoffmanLabs LLC

Where's the documentation on "how to build and deploy software on the 
platform" for other OSes?

There's more stuff written than you can shake a stick at for Windows
and Linux. If anyone can find consistency and correctness in what passes
for their documentation and associated support material (forums, blogs,
etc), I'll be amazed. If anyone can predict what the volume OS
environment might look like in three years time I'll also be amazed. 

But those two are low value high volume rapidly changing OSes. VMS
isn't a low value high volume rapidly changing OS. Historically, VMS
(and products associated with VMS) haven't had the same volume of
stuff written about it as those two have had, but the VMSworld stuff
has typically been helpful and definitive and logical, and indeed it's
often been consistent over time. Those attributes seem to have become
unfashionable.

So, what specifically needs to be done next wrt "how to design and
deploy VMS systems and software"? Especially given that Containers
and Docker are on the published VSI roadmap.

Does VSIVMS have to be "the same as everywhere else" in this
respect? That's one approach to the volume market, but it requires
tools and facilities (and market consensus) that don't exist today,
even if the tool prerequisites existed in the past (e.g. VMS POSIX),
or might exist in the future e.g. some form of Win32 API, er sorry
.NET compatible runtime, er sorry Win64-under-VMS virtualisation,
or whatever. 

Or would a decent supported implementation of a few strategic tools
such as a Python, recent JAVA, whatever, be a good start? Don't see
how it would be *enough*, but I do see how it could be helpful.

And/or are you suggesting that VSIVMS can largely go its own way in
terms of designing and deploying software, much as it has done for
the last three and a bit decades) but it needs a bit of formalising
and documenting?

That would seem a very fair suggestion, but it may not be VSI's top 
priority. As it's VMS it may also be the case that there may be
more than one possible acceptable way to do things right (and even
more ways for those new to the game to do things not right, as is
so frequently visible in InternetOfTat designs and deployments right
now).

Once upon a time "going your own way" might have been an opportunity
for a book or two documenting a set of recommendations and practices,
perhaps even a book endorsed by the OS vendor. And/or perhaps for
some enterprising group(s) to offer consulting services, again
perhaps endorsed by the vendor. 

Or at the very least, a helpful user community willing to take
questions and provide initial credible helpful answers, perhaps 
without relying on the hardware vendors own "support" mechanisms.

There may well be other possibilities too.