[Info-vax] Dependencies and Calling Standards

[Stephen Hoffman]

On 2018-12-16 21:08:19 +0000, Dave Froble said:

> 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:
>>>> 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?

The C standard library is a large part of what composes the Unix system 
services on Unix.

With Microsoft and .NET, it's .NET (and the CLR) that provides the 
system interface.  Which is why various Windows apps ship with a NET 
installation.  There are usually trade-offs, too.  In place of DLL hell 
you get parallel .NET installs.   And most of us have met variations of 
DLL hell on OpenVMS too, with SHRIDMISMAT and friends.

> As one example, can I mention FORK?

Have at.  fork is one of the more fascinating Unix calls, and few folks 
will use it for what it can provide.

There's some source code around that just gets embedded everywhere, and 
latent bugs in that code can cause issues.

(There's one of these latent-bugs cases going right now, too. Haven't 
yet verified whether or not OpenVMS is effected.)

I can mention piles of wonderfully non-portable code written on and for 
other platforms, too.

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

C, Fortran and COBOL have all gone over.  Haven't bee involved with a 
BASIC port, though.  FreeBASIC, Decimal BASIC and various other options 
are available.

As for BASIC and IDEs, haven't looked at that.

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

SQLite is available on OpenVMS.  PostgreSQL is blocked behind some 
OpenVMS C I/O bugs; behind what's been known as SSIO.

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

Clustering needs substantial remediation, as do other areas.  Striking 
a balance between scheduling shorter-term requirements and the 
longer-term efforts to reduce technical debt and to provide substantive 
enhancements is never easy.




-- 
Pure Personal Opinion | HoffmanLabs LLC