[Info-vax] Somewhat levels up to not port outside VMS (letter from Wyoming)

[johnwallace4 at yahoo.co.uk]

On Thursday, 13 December 2018 13:02:03 UTC, Neil Rieck  wrote:
> On Thursday, November 29, 2018 at 7:35:29 AM UTC-5, gérard Calliet wrote:
> > It has been said about a proposal for an old VMS customer, where I 
> > concluded “I’ll try a proposal to upgrade to some 8.x VSI VMS for 
> > Alpha”, that:
> > 
> [...snip...]
> > 
> > Gérard Calliet
> 
> I am glad we ported our code from VAX/VMS to OpenVMS/Alpha
> http://neilrieck.net/docs/openvms_notes_alpha_diary.html
> then again to OpenVMS/Itanium
> http://neilrieck.net/docs/openvms_notes_itanium_diary.html
> but our ecosystem is populated by technical people (nerds) who understood the problems then proceeded forward anyway. I am currently involved with a couple of related projects in the corporate ecosystem which is populated my MBA dweebs. These people want absolutely "zero surprises" so I am afraid I would have to agree with the project lead that the only way forward is to go with an Emulation solution like Charon-VAX running on some sort of x86-64 platform like a DL385.
> 
> p.s. this is not the way to go if you need new functionality like "adding a web server"
> 
> Now I need to point out that MBA-types may be prolonging the inevitable in deferring to someone coming in behind them. In the case of VMS or OpenVMS, many hope that the system can be ported later (harder after you loose talent) or the company can eventually migrate to some sort of cheaper wiz-bang Linux solution. I can tell you that going the Linux way can open up a whole new problem as I have documented here:
> http://neilrieck.net/docs/openvms_notes_linux.html#realworldlinuxproblems
> 
> The biggest problem with Linux is that you can inadvertently change the system during an upgrade, which will break something else. Then it is impossible (or virtually so) to roll back.
> 
> p.s. I have always been able to rollback an upgrade in OpenVMS or Windows 
> 
> I have first-hand knowledge of how this Linux problem is handled in "customer owned / IBM-managed" data centers (my employer has several). IBM will not give ROOT or SUDO privs to anyone without first submitting a written request then you need to wait 4-8 weeks for the response depending upon the urgency.
> http://neilrieck.net/docs/openvms_notes_linux.html#ibm_managed
> 
> Other people may have a different spin on these issues but this stuff happened to me as I have written it.
> 
> Neil Rieck
> Waterloo, Ontario, Canada.
> http://neilrieck.net


Are you satisfied with the backup of your system's disks?

It doesn't just apply to VMS. And actually, it's not the backup
that matters, it's the ability to restore it (or recreate an 
equivalent) and carry on from something resembling where you 
left off. It's helpful to know in advance whether you stand 
much chance of it working right. In your picture, with Linux
systems managed by external commercial contractors (same
company that does the admin is also the one that owns the OS
provider, right?), who is technically and financially 
responsible for making sure that systems can be restored or
rebuilt?

(2) This would all be fine if you were using (someother) 
Linux/BSD etc. My favourite Linux of the Week has been 
Suse, for a decade or more.

(3) Have you considered blaming any problems on systemd? 
Lots of Linux/BSD/etc folk seem to be doing it, and I 
don't like the sound of systemd much, but it hasn't 
broken any of my Suses yet, so far as I know.

(4) The cult of "seagull management" vs "continuous
improvement": if things don't change, they're not 
improving, so high-flying managers come in, cover the
place in .. (eg by changing stuff that works) and reap 
their rewards and move on before the changes are seen
to be disasters in waiting. Been there, seen that,
not a bright idea in critical systems expected to 
last longer than a few seasons. 

Still, what could possibly go wrong.