[Info-vax] OpenVMS Development Annoyances

Dave Froble davef at tsoft-inc.com
Tue May 7 14:14:30 EDT 2019


On 5/7/2019 1:49 PM, Stephen Hoffman wrote:
> 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.

One thing seems clear to me.  Inter-system communication use will only 
expand.  It's here to stay.  So to address this trend (that I see) I 
feel that some attention from VSI would be a good thing.  When they can.

Even with the item lists and the QIO interface, I find socket 
communications rather simple.  Mostly.  Then there is the midden heap 
called HP TCP/IP.

Currently I'm blaming myself, and I haven't looked at it lately, but I 
feel it should not be so hard for a listener to create a shared socket, 
start up a worker thread (process) which opens the socket and takes over 
from that point while the listener closes the socket and forgets about it.

I've got an idea what is going wrong, and how to fix it, but I got so 
disgusted that I vowed to wait for the new TCP/IP from VSI.  Things are 
coming up which will perhaps desire the capability.

Regardless, there is the issue of secure communications.  I got it 
working, (with your help) and it was so confusing (to me) that I figured 
that if I put it into production, some future maintainer would get lost 
looking at it.  That's very bad for production code.  So I'm letting you 
lead the charge for better (is good too much to hope for?) certificate 
capabilities on VMS.


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



More information about the Info-vax mailing list