[Info-vax] OpenVMS Development Annoyances

[Stephen Hoffman]

On 2019-05-07 16:46:40 +0000, Dave Froble said:

> Oh, I see it Steve.  There is a part of me that asks why there isn't:
> 
> TCP$Create_Connection_Socket( ,,,,, )
> 
> Where I can pass required arguments and get back a completion status.
> 
> And many times more so:
> 
> TCP$Negotiate_Certificate_Handshake( ,,,, )
> 
> Many, many times more so ....

That's part of the effort.  The other part is just the API clutter that 
is the itemlist and related baggage.   Most of us are so accustomed to 
writing and reading the glue code, we simply become inured to it all.  
Really seeing the baggage code was an epiphany.    Folks new to 
OpenVMS?  They'll tell you about this baggage code.

> Will there ever be such a routine, for VMS, and not C specific?  I 
> don't know.  As you say, VSI is quite busy.  And there is the 
> possibility some might say "do it in C".
> 
> One of the problems is that TCP/IP came from Unix, and things in Unix 
> seem to be rather tied to C.  Thus, we have HP TCP/IP which really 
> doesn't fit in VMS and the VMS way.
> 
> What is the VMS way you might ask?  Well, for starters, there is LIB$ 
> and STR$ and ....
> 
> Perhaps a TCP$... set of routines might be nice?
> 
> But my point is, if I'm using VMS, I use what's available, and it's not 
> quite as bad as you say it is.  Sure could be better.  But, today is 
> today, and we can't wait for wishes.

Of course.

Many folks probably won't be familiar with OpenVMS, and may well choose 
different platforms.

None of us wants to slog through sockets and TLS. Not if we can avoid it.

Trade-offs can be that our apps are also either more expensive or less 
capable, too.

We're busy re-inventing.  Or we're ignoring.  Or we're creating 
exploitable code.

And VSI is buried in work, not the least of which is the x86-64 port.

> As for your example, if I understand it correctly, yeah, it might be 
> "easy" to use a tool that "does everything", but it looks to me like it 
> also might be a bit rigid?  As an example, and yes, from using VMS, if 
> I already have a channel open, why can't I just use that instead of 
> "re-inventing the wheel" by having the OO tool do work that is already 
> done?  Or, maybe I didn't understand the example well enough.

The knobs are available.  We just don't have to deal with the knobs 
until and unless we need to.

> I agree with your thoughts, and nowhere more than in the use of certificates.

Here's an ~hour-length presentation video of explaining and developing 
an app for UDP live streaming of video, using a recent network 
framework intended to abstract a bunch of the coding and API baggage 
we're all dealing with.

https://developer.apple.com/videos/play/wwdc2018/715/

The source code is written in Swift as is Apple's wont of late, though 
the structure and operations of the sender and the listener should be 
clear, as well as some cases which long-time server apps are only just 
starting to deal with; proxies, IPv6, etc.

Whether VSI ever creates an API like this?   Understanding various 
solutions and better understanding OpenVMS itself—better understanding 
the parts that many of us no longer notice, or that we take for 
granted—goes a long way toward improving our apps and our products, and 
toward understanding what new developers are experiencing, and what is 
costing time and effort to create and maintain for existing developers 
and existing apps.  And toward an understanding of some parts of the 
mountains of work ahead for VSI.

Is this API one to use?  Unclear.  I do know that mistakes are easy 
with sockets and TLS, that certificates are an unmitigated mess on 
OpenVMS, and that the socket-related work I've been doing hasn't had to 
deal with proxies, and that few of the apps have had to deal with IPv6 
as few of the OpenVMS servers have moved to IPv6.  Yet.



-- 
Pure Personal Opinion | HoffmanLabs LLC