[Info-vax] OpenSSL 1.1.0 released

IanD iloveopenvms at gmail.com
Sat Sep 10 19:54:36 EDT 2016


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



More information about the Info-vax mailing list