[Info-vax] Access to _all_ VMS system services and library functions from DCL ?

[Stephen Hoffman]

On 2017-07-13 01:18:13 +0000, David Froble said:

> Stephen Hoffman wrote:
>> On 2017-07-12 20:12:18 +0000, David Froble said:
>> 
>>> Simon Clubley wrote:
>>>> 
>>>> This scheme instead would be pretty close to 0% upwards compatibility.
>>> 
>>> Not true at all.  All the code you've written, with the exception of 
>>> usage of "changed" system services, will still run.  No re-build 
>>> required.
>>> 
>>> The alternative would be to stiffle improvements.  Which would you choose?
>> 
>> You're rebuilding OO.   Badly.
> 
> I don't care if it's OO, or something else, as long as it's callable, 
> easily, from all VMS languages.

That's certainly a part of the effort.   The other part is implementing 
those changes in such a way that we don't have to (unnecessarily) keep 
revisiting the source code for rebuilds or for rework.   It's a 
balance, certainly.   Total compatibility seems great right up until 
you're change-deadlocked and can't fix things, and free-for-all changes 
are just as bad.

An OO approach is a completely different approach from what's been 
classically used with OpenVMS libraries and frameworks.   It's quite 
common on some other platforms, and it's something that OpenVMS can 
learn from and OpenVMS folks can use.   Microsoft .NET and the Apple 
Cocoa APIs are two examples.   It's something that solves what you're 
headed for with your records and data structures, avoids the overhead 
of populating a big record all at once as was mentioned else-thread, 
and it also avoids the need to deploy component upgrades en-mass.   The 
approach also has some similarities to how SQL databases work, too.  (I 
won't go so far as to point to Nix 
https://www.linux.com/news/nix-fixes-dependency-hell-all-linux-distributions 
as having a clever way to do those incremental upgrades easier, and a 
similar approach is certainly workable on OpenVMS, but I digress.)

Any design would need to be integrated with the major OpenVMS 
programming languages.   A big record requires minimal language 
changes, but and some changes in a few places to (for instance) verify 
the format of the data structures returned; version compatibility 
checks, etc.   I wouldn't expect to see some of the programming 
languages go OO here, and for various reasons.  For those, I'd expect 
to see them continue to use the existing system services and RTL calls, 
and to be jacketed for any OO APIs.  Getting the necessary data into or 
out of the Cocoa APIs using Objective C is quite possible, as it's 
still C underneath.

As for which languages are the most active on OpenVMS, and where to 
concentrate the development effort here...  I certainly don't know what 
the OpenVMS programming language usage is, and I'd wonder if VSI even 
knows anything beyond license sales; there's no instrumentation nor 
telemetry to acquire and track these sorts of details after all, and 
there are the obvious discussions around confidentiality and 
anonymization.

> Now, are you saying if it's not what you want, that it's automatically wrong?

Automatically?   Nope.

> Improvements are improvements.

Though some changes are not improvements, and some improvements are 
mortgages against future effort, and there are a few 
were-once-improvements that could now best be addressed by removal.

> They do not all have to follow some specific guideline.

While I'm in favor of making certain changes that might break app 
compatibility for good and specific reasons, improvements that require 
repeated app source changes or incremental rework in the same area, or 
that require app rebuilds, or system-wide all-at-once upgrades aren't 
going to be particularly popular.   That's where the approach you're 
suggested with a big structure populated with data is headed.    That's 
basically what we have with SYSUAF right now.   That same approach is 
also analogous to what happened with the moves from HPE SSL prior to 
1.4, to SSL 1.4, and again to SSL1, and what will probably happen again 
for the apps with the next big OpenSSL update.  That approach does 
certainly work, of course.  That's not the question.   It's just that 
there are some other and arguably better ways to implement that.  To 
learn from what other systems and designs provide.   I don't really 
want to be maintaining and upgrading data stores using fields stuffed 
into RMS record structures now, much less in 2027.



-- 
Pure Personal Opinion | HoffmanLabs LLC