[Info-vax] Taking a break - Open Source on OpenVMS Conference Calls Resume in the FALL of 2022...

[seasoned_geek]

On Thursday, June 16, 2022 at 7:15:37 AM UTC-5, Simon Clubley wrote:
> I am surprised that no-one else has offered any comments about this or 
> about how they see, at a technical level, the best way forward for 
> porting open source software to VMS.
> Simon. 
> 
Well, as someone who had to write something to catch all OPCOM and some other messages creating modern syslog format (forget the number then) using C when the C compiler was about 10 years out of date so had to port the bulk of the GNU string library into the project before I could get anything to work . . .

There isn't one.

Operating systems and written on the x86-wanna-be-a-real-computer-one-day-when-I-grow-up platform never scale up.

You can scale a real OS and real software down because you are taking things out, but the x86 platform is inherently so insecure and non-robust you can't really port anything of significance to OpenVMS.

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.

Many didn't take it to that level, but you could.

The best, won't say where, won't say when, were the sites that re-purposed the "Test Cluster" as a glorified terminal.

All of the real software was loaded on this system. It was used for integration testing and new user training. It even had regularly scheduled nightly jobs. The operators sneaker netted actual inventory files over to the system each night. On the "Test Cluster" the critical files all had generic names like INVENTORY.DAT, INVOICES.DAT, etc. Completely different names on the production cluster.

The production cluster had no outside access. To get a terminal on it you had to go through the "Test Cluster" with your magic-magic access code to a magic-magic program that would open a basic terminal connection to a production cluster on a different network. It was a specific non-generic terminal package that would only connect with itself, I don't remember what. They might have rolled their own.

The only "outside access" the production cluster had was via MQSeries queues from a Websphere server. There was no way to initiate any kind of file transfer or terminal connection from the outside world. All of the free-flowing XML/JSON/etc. messages were converted to fix-width fixed-field-width proprietary message formats before being placed on the queue. 

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.

The x86 world doesn't have this. More importantly can't be made to deal with it. To make OpenSource software of any significance run correctly you end up with one-off forks because what you need can't be passed back upstream. 

Yes, many small useful things like JED https://www.jedsoft.org/jed/ can be ported. I use JED a lot in my embedded systems work.

Instead of having huge range of exit codes that can convey $SEVERITY one can only safely use 0-125 and 0 **is the only success value**

https://unix.stackexchange.com/questions/418784/what-is-the-min-and-max-values-of-exit-codes-in-linux

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 . . .

I say it would have made a lot of sense only because OpenVMS could then become a robust host OS for a robust relational database that all of the x86 languages that matter could hit. Would have granted much purpose to the x86 port, especially if the COBOL/BASIC/FORTRAN/C compilers got a PostgreSQLMod utility so shops could begin migrating applications from RDB to a free-as-in-beer database the new maintainers of VMS could sell support contracts for.

I suspect that was a giant hill to push a boulder up though.

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