[Info-vax] Updated HPE/VSI OpenVMS V8.4-2L1 Marketing Brochures

[Kerry Main]

> -----Original Message-----
> From: Info-vax [mailto:info-vax-bounces at rbnsn.com] On Behalf
> Of Stephen Hoffman via Info-vax
> Sent: 01-Oct-16 12:11 PM
> To: info-vax at rbnsn.com
> Cc: Stephen Hoffman <seaohveh at hoffmanlabs.invalid>
> Subject: Re: [Info-vax] Updated HPE/VSI OpenVMS V8.4-2L1
> Marketing Brochures
> 
> On 2016-10-01 14:56:24 +0000, Kerry Main said:
> 
> > While ports are available on different platforms, Apache and
> nginx are
> > native *nix developed so have a *nix focus of development.
> 
> Okay.    So?   Keep going.   What are you implying with that?    Unix
> and particularly Linux are the predominant competitors for
> OpenVMS, as well as an exceedingly large source of software, as
> well as the server platforms that OpenVMS will be commonly
> interoperating with in most
> environments.   They're fine platforms, with many good ideas and
> some
> of which are well worth borrowing and improving upon, yes and
> with some bad ideas and bad designs and frustrations in other
> parts, and Unix and Linux systems can be easier to manage and
> deploy and develop for than
> is OpenVMS.    If VSI wants to grow past the current OpenVMS
> installed
> base, the VSI folks will have to gain customers that might
> otherwise have deployed Unix and Linux, which means VSI needs
> to understand the advantages and disadvantages and cost
> advantages and cost disadvantages
> of those platforms, too.   As compared with OpenVMS.
> 

Where did I say they were not good options?

The issue is that while many of these non-OpenVMS product options work just fine on OpenVMS, there are porting issues like fork which are unique to *nix architectures. Hence, different workarounds need to be put in place which may not necessarily be the optimum way of doing things on another platform like OpenVMS or even Windows for that matter.

Also, how many of these open source options support active-active shared disk clustering which on OpenVMS allows scaling by transparently adding servers without changing any application code such as that required when dealing with DB sharding in shared nothing designs?

Btw, Apache is a nice exception because it does support OpenVMS shared disk clusters.

Getting something to work on another platform does not necessarily mean it is optimally tuned for that OS's strengths.

> > IIS is a good example where the vendor Microsoft has
> developed a
> > platform specific alternative to Apache/nginx. While many could
> argue
> > which web solution is better on a Windows platform, there are
> a lot of
> > Windows focused groups who do IIS because it is a native
> Windows
> > solution.
> 
> Microsoft is a wee bit larger and better funded than is VSI, and
> with a
> slightly larger customer base.   If VSI gets to the scale of
> Microsoft?
>   The calculations then differ.  Slightly.   Right now, VSI doesn't
> have enough staff for what they have written on their
> whiteboards — not by any stretch — and VSI just did an
> acquisition of an IP stack, and that's before discussing taking on
> the continued development and
> maintenance of project of the scale of a web server.   Whether
> that
> starts with WASD and hiring folks familiar with same, the
> development of a new stack, or otherwise.  For now, Apache
> likely means somewhat less customer training is required; folks
> already know that.
> 

As stated above, Apache is an exception as it is popular and also supports shared disk OpenVMS clusters.

> > Imho, the bundling of a solution developed specifically for a
> platform
> > e.g. WASD does not prevent an alternative solution like Apache
> from
> > also being used on a specific platform. A pre-installed Apache
> on LD
> > container similar to how Perl is distributed on OpenVMS might
> be one
> > option.
> 
> Having Perl and Apache integrated into the distro and always
> present
> would be far better.     Having to deal with the configuration
> permutations of separate installations means more code in
> OpenVMS and in layered products and third-party packages,
> more testing complexity, more risks of failures as the software
> versions skew, and more than a few projects that simply won't
> use or won't require the tools because
> they're not always present.    In short, this approach continues
> with
> the same scatter-shot software platform strategy currently in
> use, and with the addition of another patch path and yet another
> update strategy required, and with a completely different way to
> find out if the pieces are present, and with no obvious way to
> place a front-end on any of
> this to reasonably manage what's installed.   That's not forward
> progress.
> 

An LD approach like Perl is pretty brain dead simple. Create/mount the LD drive and update the startup file.

> > In terms of overall solutions enhancement, I remember what a
> Microsoft
> > Engineer told me one time - the biggest driver for new features
> and
> > enhancements to the core Windows platform did not come
> from Customers,
> > but rather the internal SQL Server, IIS and Exchange groups at
> > Microsoft. In other words, the Windows core was not being
> enhanced for
> > other vendor products.
> >
> > That’s a pretty amazing concept - support other options like
> Apache,
> > but focus major core improvements on platform specific
> solutions.
> 
> I'd been my experience that customer-facing polling will give you
> very few new ideas, and what feedback received — and as
> happened at the most recent boot camp — will seek to dissuade
> development from changing the platform in any incompatible
> fashion, and — where changes can or do occur — will trade off
> current software investments and approaches for (often greatly)
> increased future development work and future management
> much more difficult, delayed release schedules, and such.   It's all
> a
> trade-off, of course.  But I'd prefer it if VSI had the conviction of
> their decisions, and started looking forward.   Because that's what
> brings new users.   Compatibility with the past is what makes 64-
> bit
> addressing such a mess to deal with.  Customers don't (yet)
> understand the value of changes and newer approaches, and —
> unless the questions are asked very carefully — will err toward
> avoiding costs and changes
> with their current platforms.   Quite justifiably preferring to avoid
> any changes, in many cases.   But that subset of sites — those
> sites in
> environments or organizations that can't or won't change —
> shouldn't be dictating the future of the platform.
> 

Compatibility with backwards versions is an issue for all OS vendors - it's not unique to VSI.

Just ask Microsoft or Red Hat.

Sample reference:
https://access.redhat.com/articles/rhel-abi-compatibility


Regards,

Kerry Main
Kerry dot main at starkgaming dot com