[Info-vax] Open Source on OpenVMS (was: Re: Taking a break...)

[seasoned_geek]

On Thursday, June 16, 2022 at 2:11:32 PM UTC-5, Stephen Hoffman wrote:
> On 2022-06-16 13:50:16 +0000, seasoned_geek said: 
> 
> 
> As for syslog, there's an old port at VSI: 
> https://vmssoftware.com/products/syslogd/ 
> 
That's a train wreck that got hit by a plane crash and is rolling downhill towards a daycare center at noon play. I think there was almost 20 "working examples" my client found for me. They tested only under SYSTEM. Every one of them was worthless junk. Un-initialized pointers, wrote to buffers they never allocated. Uninitialized numeric values. List went on and on. When you ran them as a mere mortal with just a couple of added privs for the function calls they all self-destructed.

I also needed the "modern" layout in use by RSyslog at the time.

> > Operating systems and written on the 
> > x86-wanna-be-a-real-computer-one-day-when-I-grow-up platform never 
> > scale up.
> x86-64 servers are substantially more capable than the Alpha and 
> Itanium boxes that many of us are dealing with. 
> 
Sorry, but you completely missed the point here.

https://www.logikalsolutions.com/wordpress/information-technology/business-class-computing/
https://www.logikalsolutions.com/wordpress/information-technology/soversion/

Speed is not the problem. Lack of skill and architectural design is the problem. The completely worthless and criminally fraudulent AGILE stuff isn't helping the x86 world get any better. You cannot architect a valid solution for thousands of users jumping straight into coding looking no further ahead than six inches in front of your shoes which is what AGILE TDD CI/CD does.

The focus of the operating systems originally written on x86 platforms has been single user. Eventually access for a few other users was hacked on. Even Linux has processes too light to be considered threads on VMS which is why there are hundreds, possibly thousands, of articles written on how to kill dangling threads.

It's not a hardware issue, it's the itty-bitty brain behind the software and the OS.

> > Despite what many others in here may wish to promote, layered logical 
> > name tables with user, group, and ACL access security is a robust and 
> > amazing security feature when properly used. Applications using these 
> > features in an appropriate manner can be self-protecting with the 
> > default super user tree pointing off to an "entertainment value" area 
> > of the system that can send a security alert and keep the user poking 
> > around for hours while teams/authorities backtrace the connection. You 
> > have to "know the magic codes" to get out of the "entertainment value" 
> > tree into the actual tree where all of the actual accounting, customer, 
> > cc, etc. information is.
> You've also just described LDAP. 
> 
No, I didn't.

> Pragmatically, all of the logical name stuff could be re-hosted over 
> onto LDAP and with minimal or no disruption, and with support for 
> multiple hosts and replication added.
No, it can't.

I know you have hated logicals since you went over to the dark side, but they are the one crown jewel and none of the cheap PC implementations come close to them.

> > Many didn't take it to that level, but you could.
> Most will use parallel LDAP, if they want or need full separation.

No. We will continue to use logicals.


> These same messes can arise with OpenVMS, and this mess is unrelated to 
> the underlying processor architecture.

I didn't say it was. Tiny x86 minds are the problem.

> Outside of its own non-production data, there's no reason for the test 
> environment to diverge from productions, and often various good reasons 
> why it should not. The more test diverges, the more time spent testing 
> divergences.

Oh, there are numerous good reasons for Test != production. How else are you going to test a new OS release or patch for one.


> A combination of access controls and DNS are commonly used to direct 
> clients to the appropriate servers.

Nowhere near as secure.

> That's server isolation is a fairly common preference, and independent 
> of the processor architecture.

Will let this one go because earlier in this message you assumed I was talking about the processor. I was talking about the engineering mindset of VMS and all applications written for it. Simply does not exist in the x86 world.

> > I took that tiny detour to point out the level of thinking that want 
> > into many/much/a-not-insignificant-part of the VMS world. People 
> > actually thought about things like bifurcated terminal applications and 
> > other secured communications. We have $SEVERITY with many different 
> > values that qualify as $SUCCESS because the values were deemed 
> > INFORMATIONAL.
> None of what you've described so far is unique to OpenVMS. 

It was unique to VMS __and__ nothing on the x86 comes close. When you look around on the x86 platform for comparable things it's like looking around at the women left in a bar at closing time.

> 
> Some other error reporting via error classes are far more flexible, for 
> newer environments. 
> 
> Here's the older NSError, as an alternative to what OpenVMS does: 
> https://developer.apple.com/library/archive/documentation/Cocoa/Conceptual/ErrorHandlingCocoa/ErrorHandling/ErrorHandling.html 
> 
Real developers don't use Apple. The language of business is COBOL and those classes won't work with COBOL.

> > The one package that shoulda-woulda-coulda made a lot of sense was 
> > PostgreSQL because it actually started out on VMS decades ago. 
> > According to the port page 
> > https://wiki.postgresql.org/wiki/OpenVMS_port 
> > last updated 2012 . . .
> PostgreSQL hasn't ever supported OpenVMS. (You're probably confusing 
> PostgreSQL with Ingres or some other database package which did have 
> support for VAX/VMS or OpenVMS.) 
> 

Not confused. Some number of years ago, early in the PostgreSQL world I was exchanging emails with one of the main developers. PostgreSQL started with the Ingres code base which built on VAX. None of the x86 minds working on the port wanted to keep working on VMS. Possibly none had access to a system.


> The PostgreSQL port stalled due to shared stream I/O corruptions (SSIO) 
> latent in OpenVMS, among other issues. 
> VSI is reportedly addressing those corruption issues for single-host, 
> non-clustered apps. 
> 

Long way from first time the port failed.

https://wiki.postgresql.org/images/d/d3/PGConf_2015_VAX_Lightning.pdf

Actually rather hilarious read.

> VSI does seem intent on a port of PostgreSQL. Probably as an option or 
> fallback, should Oracle Rdb be delayed or unavailable or otherwise 
> under- or uninteresting to VSI customers. 
> 
DEC screwed the pooch here back when I worked at LIOCS. They briefly were including RDB run-time but shafting the VARs royally for a Development license. As such, all of the VARs stuck with RMS indexed files for their applications. The landscape is littered with ERP, CRM, and other canned packages which could have made the jump and kept the platform relative. Now there are huge corporations trapped on systems from vendors that no longer exist. God-awful hacks got done to export "historical" data that had to be kept in the system but RMS indexed file size limits were routinely being hit. The job you would have to run once every 5-7 years became a monthly scheduled job and yes, you had to use a logical name table to keep the history file search path dynamically updated.

Oracle will squeeze the orange with RDB. If enough juice doesn't come out they will kill it. Having PostgreSQL as the standard cluster-aware ACMS-transaction-aware database installed for free and by default will go a looong way towards giving VMS a tiny remaining purpose.

> > Lack of any real desktop for VMS torpedoed adding support to a large 
> > C++ framework like CopperSpice or Qt that would have hidden most of the 
> > ugly OS details
> Absent massive and likely futile investments, OpenVMS on the desktop is 
> and will remain uninteresting outside of the installed base, and 
> outside of those few hobbyists with unusually low app expectations, and 
> outside those not requiring interoperation with other common desktop 
> apps and formats. Insufficient Phillips for meaningful profits. 

The point is, all of the well tested USB, serial port, SQL, et-al high level application routines are in large frameworks like Qt, CopperSpice, wxWidgets, etc.