[Info-vax] OpenSSL 1.1.0 released

[Kerry Main]

> -----Original Message-----
> From: Info-vax [mailto:info-vax-bounces at rbnsn.com] On
> Behalf Of IanD via Info-vax
> Sent: 10-Sep-16 7:55 PM
> To: info-vax at rbnsn.com
> Cc: IanD <iloveopenvms at gmail.com>
> Subject: Re: [Info-vax] OpenSSL 1.1.0 released
> 
> On Tuesday, September 6, 2016 at 1:41:23 AM UTC+10,
> Stephen Hoffman wrote:
> > On 2016-09-05 15:12:45 +0000, Richard Levitte said:
> >
> > > I see what differs, and probably why yours works; In
> my case, the only
> > > difference was that the source was in different
> directories...
> >
> > Remember that flat directory comment?
> >
> > PCSI could be so much better with an actual database
> underneath and not
> > the RMS morass, and with some fixes and
> enhancements, and maybe with a
> > look around at what PCSI is actually doing with all
the
> disk I/O it
> > tosses out, and for a two-file install, but there are
> undoubtedly many
> > other projects and improvements much higher on the
> schedule.
> >
> >
> > --
> > Pure Personal Opinion | HoffmanLabs LLC
> 
> Even humble sqlite would be a good fit as a db
> underneath many of the OpenVMS information
> repositories although getting something like PostgreSQL
> fully working on OpenVMS might lead to bigger and better
> things
> 
> I think from memory, sqlite is multi-reader but limited
to 1
> writer at a time, might be a limiting factor in some
> instances ?
> 
> How I have longed for files like sysuaf.dat to be in a
DB
> format beyond a simplistic RMS indexed file format
> 
> How about log files stored as xml/JSON or at least every
> utility having the option to input/export in those
formats?
> 
> When RDB added xml as a table output / import format ,
> it's usability for interfacing from simple script access
when
> up immensely.
> 
> OpenVMS could do itself a lot of favors by having these
> near universal data exchange methods on tap across it's
> utilities and interfaces, not only for external world
> interfacing but also to assist the system manager and
> automated bots - it's such a PITA to have to continually
> work with differing formats that you have to parse /
filter
> over and over again to get at what you want.
> 
> How many times does one start a new job at a place and
> then get asked to create some new type of report and
> then start the whole script re-invention coding again
> because the log file / data file has some unique layout?
> Boring and repetitive, it's time for OpenVMS to support
> people not make people work with native, somewhat
> stone-age formats and utilities
> 
> We have the The Common Log Format for web servers, is
> there a universal log file format anywhere? Does
> OpenVMS actually stipulate a guideline for log file
formats
> or is it a free-for-all? It sure seems like a
free-for-all, even
> looking at the OpenVMS internal log file formats
> 
> Perhaps we can develop something? or move towards an
> xml/JSON structured one? We some some proper base
> classes for OpenVMS from which to build upon
> 
> I know these formats can get a bit long winded when
> reading an extensive log file but that can be worked
> around by pointing a browser at the log file and letting
it
> deal with the tags and prettying it up and/or once it's
in
> these universal formats you can run some tool over them
> anyhow and down select the major data types you are
> after anyhow.
> If your a real masochist you still have the option of
dealing
> with the raw data if you want anyhow.
> 
> The big take is that OpenVMS needs to move forward and
> DB's add a hell of a lot of value as does using
universal data
> exchange formats like xml/JSON
>

Log files in a formal OpenVMS Prod/dev environment need to
be part of a cluster aware, scalable DB.  Hence, if using
an open source DB, it needs to be one that is cluster
aware and R/W from many different sources at the same
time.

Console messages,  error logs, audits etc. in a prod
environment are now not only being handled formally on OS
platforms, but being centralized as part of an Operations
Bridge environment. In fact, larger OPS Bridge
environments are now using prods like Splunk (expensive!)
to analyze log files from many sources as part of a Big
Data strategy for proactively identifying and resolving
issues before they impact the business and/or end users.

Proactive security analysis also requires a big data
strategy to log file analysis.

https://www.splunk.com/en_us/products/splunk-enterprise.ht
ml
https://www.splunk.com/en_us/products/splunk-enterprise.ht
ml#E1OW5iMjE6kvoCE7mXcyJLohGEr7J2qJ (Video)

Splunk competition:
https://www.quora.com/Who-are-the-biggest-direct-competito
rs-to-Splunk


Regards,

Kerry Main
Kerry dot main at starkgaming dot com