[Info-vax] Dependencies and Calling Standards

[Dave Froble]

On 12/16/2018 2:10 PM, Stephen Hoffman wrote:
> On 2018-12-15 18:29:01 +0000, Dave Froble said:
>
>> On 12/15/2018 1:14 PM, Stephen Hoffman wrote:
>>> On 2018-12-15 17:08:48 +0000, John Reagan said:
>>>
>>>> The spread of OpenVMS languages is not what the rest of the world
>>>> expects.
>>>
>>> There's no small difference between the expectations and experiences of
>>> the current OpenVMS installed base and those of others.
>>
>> Probably rather true.  VMS users demand better.
>
> And are willing to accept much worse, in some areas.  The developer
> tools are a bit of a mess, around the lack of a modern IDE, and around
> having to integrate other development tools.  And missing frameworks and
> libraries.  But these tools do matter for folks looking to allow OpenVMS
> to coexist with or to add support for OpenVMS.  Some of the motivation
> for developers to use clustering as part of a software source code
> platform migration effort is reduced when git or mercurial is in use,
> for instance; a different approach to the problem.
>
>>> Also part of why porting off of OpenVMS is often expensive.
>>
>> Because other systems don't provide reasonable capabilities?
>
> More than a little of the OpenVMS code was not written with portability
> in mind, and tends to be filled with RMS calls, with system services and
> itemlists and RTL calls, with extensive DCL, and with other
> less-than-portable constructs.

I have to assume that the equivalent of RMS, system services, and such, 
is also used on other systems?  As one example, can I mention FORK?

> I am well aware of some very large OpenVMS projects that were ported off
> to Linux and quickly, though those projects had worked to isolate the
> system dependencies.

Ayep, that is the way to do such.  But I have to ask, what were the 
implementation languages?  Something compatible would have needed to be 
available on the target.  If not, things get a mite more difficult.

>>> And why porting onto OpenVMS is often expensive.
>>
>> Because other systems use unreasonable capabilities?
>
> Finding and porting over dependencies and prerequisites, and—prior to
> the arrival of the work that VSI has undertaken—with downgrading source
> code to older compiler standards, among other details.
>
> Dependencies on PostgreSQL or SQLite, too.  These tools and these
> frameworks matter matter less for the traditional and existing apps
> found on OpenVMS.

I'm looking forward to those getting to VMS.

>>> OpenVMS is weird.  And at times, not in a good way.
>>
>> Why, because it hasn't (at least totally) accepted that C is everything?
>>
>> Why, because of those who say "we want standards", and then declare
>> "Unix is the standard"?
>>
>> I'm curious, how many other systems are you aware of that have a
>> common calling standard, such that routines in different languages can
>> easily be used together?
>>
>> Hmmm...  perhaps not even VMS, since C doesn't really conform.
>
> The Microsoft Common Language Runtime (CLR) is what the OpenVMS calling
> standard looks like twenty years on, and after substantial improvements
> in its features and capabilities, and after evolving descriptors into
> objects and other changes.

Yes, I took a look.  Made me feel like the "old dog" that can't learn 
new tricks.  Or, perhaps "lazy dog".

> https://docs.microsoft.com/en-us/dotnet/standard/clr
> https://en.wikipedia.org/wiki/.NET_Framework
>
> Though there's little reason for VSI to chase this particular set of
> ECMA standards, that is an option.  And .NET Core and CoreCLR source
> code is available with reasonable licensing, as has been mentioned
> around here before.
>
> Biggest issue with C and C++ on OpenVMS and the calling standard was
> arguably that the languages were never extended to integrate
> OpenVMS-isms such as string descriptors and itemlists and other -isms.

We might have a clue as to where to point the finger there, but, if that 
had happened, the porting effort mentioned above might have been even 
harder.

> Which is how we ended up with $DESCRIPTOR() and descrip.h and iledef.h
> and ilk, and how C sprouted as much or more glue code than some of the
> existing programming languages such as BASIC and Fortran.  That C and
> C++ enhancement work is less interesting now, but it would have been
> beneficial many years ago.   New OpenVMS work for developers is likely
> best happening elsewhere.  Not in retrofitting current C and C++ into
> OpenVMS.  I certainly don't expect to encounter ObjC or ObjC++ on OpenVMS.
>
>
> The opportunities for VSI here involve understanding what is available
> and used on and necessary on other platforms, and around providing
> options and alternatives if not explicit support for that.  This effort
> differs substantially from working on what will help existing OpenVMS
> folks keep using the OpenVMS platform.  Clustering and RMS and the DLM
> and HBVS aren't going to particularly attract new interest going
> forward.  Not much more than what those same longstanding features have
> attracted over the past decades. And features and changes intended to
> attract new users variously won't be interesting to existing users.   A
> few might even disrupt existing users.

Well, I think you've admitted elsewhere that $25K per CPU/system to join 
a cluster is a rather big bite to swallow.  That's a minimum of $75K for 
a minimal 3-node cluster.

I'm waiting to see what VSI will do with this issue.  If they do not 
make the cluster capability feasible in today's market, then they just 
might as well remove the capability from VMS.  It will be worthless.


-- 
David Froble                       Tel: 724-529-0450
Dave Froble Enterprises, Inc.      E-Mail: davef at tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA  15486