[Info-vax] Some questions on software for VMS 7.3 VAX (Stephen Hoffman)

[Kerry Main]

> -----Original Message-----
> From: Info-vax [mailto:info-vax-bounces at info-vax.com] On Behalf Of
> Stephen Hoffman via Info-vax
> Sent: 10-Jan-16 9:21 PM
> To: info-vax at info-vax.com
> Cc: Stephen Hoffman <seaohveh at hoffmanlabs.invalid>
> Subject: Re: [New Info-vax] Some questions on software for VMS 7.3
> VAX (Stephen Hoffman)
> 
> On 2016-01-11 01:36:38 +0000, Kerry Main said:
> 
> >> More recently, HPE is getting entirely out of the OpenVMS business.
> >>
> >
> >
> > Actually, it looks like HPE is getting out of anything not based on
> > X86-64 and that includes HP-UX and Non-Stop.
> 
> 
> Ignoring The Machine, the HPE folks are now (publicly) interested in
> RISC-V:
> 
> http://riscv.org
> HPE UEFI: http://riscv.org/workshop-jan2016/Tues1415%20RISC-
> V%20and%20UEFI.pdf
> 
> They've dabbled some with ARM in the ProLiant line, including the HPE
> ProLiant m400 server cartridge.   Not that they seem to be pushing all
> that much ARM server gear lately, and the HPE Edgeline stuff — where
> you'd expect to see some ARM-based boxes — has been marketed as a
> partnership between HPE and Intel.
> 
> 
> > Case in point - HPE's new Server Mgmt product that replaces HP SIM
> and
> > other similar HP server HW mgmt. and monitoring utilities is called
> > "HPE  OneView". OneView ONLY supports specific ProLiant blade, rack
> > servers  running Windows or Linux and HPE storage and some network
> > switches.
> 
> That's not new.   The HPE vendor monitoring tools and error-processing
> tools and related seem to get rebranded or replaced every three to five
> years or so.   Not that DEC and Compaq didn't also change out these and
> related tools, too.   Not that open-source tools also don't get
> shuffled around or abandoned, as well.      As for server monitoring,
> more than a few folks are using some combination of Nagios/Icinga,
> Cacti, Groundwork, Zabbix, Munin, OpenNMS, or otherwise.   There
> were
> Nagios NRPE bits for OpenVMS, and likely some others.
> 

And that is why the DC config mgmt. world is such a mess. Each group
thinks they know better than the other group what is best from a systems
and network mgmt. perspective. Tools tend to grow from each group,
not as part of an overall service management strategy.

As an example - few groups understand that you need an Operations
Bridge function that takes events, alerts etc. from many tools, filters them,
correlates them and then does smart processing to determine if events 
are symptoms or causes of the issue. Once processed, notification should
be sent to the right group to take action and info only notification is sent to 
those groups impacted, but who need not take any action. Without this, 
you get ticket bounce i.e. event happens and all groups scramble to fix
the event e.g. switch dies and App, Storage, Server, Network groups all 
scramble before someone eventually determines it is a network issue.

The more mature IT groups will also integrate these processed alerts 
with their service desk (smart ticketing), but that requires communication 
& cooperation between groups and that unfortunately is in short supply 
in many companies today.

What usually happens is companies spend a lot of $'s (prod's, resource 
time) on products without really having a good overall and proactive
service management strategy in place. A year after spending big $'s on
tool projects, execs typically are frustrated because they do not see the 
returns or efficiencies they expected. They fail to understand that the 
custom work required to do the smart event filtering and correlation is 
very customized and requires lots of time (internal or external resources)

Note - part of a service management strategy involves tools consolidation
and that can be almost as politically sensitive as server consolidation, but
that’s a different discussion.

Regards,

Kerry Main
Kerry dot main at starkgaming dot com