[Info-vax] OpenVMS Development Annoyances

[Dave Froble]

On 5/7/2019 11:30 AM, Stephen Hoffman wrote:
> On 2019-05-07 05:40:55 +0000, Dave Froble said:
>
>>
>> On Monday, May 6, 2019 at 10:51:44 AM UTC-5, Stephen Hoffman wrote:
>>>
>>> On OpenVMS, itemlists shove a whole lot of complexity and overhead of
>>> the flexible API—and a whole lot of source code glue—into the user
>>> code, as part of maintaining API compatibility.
>>>
>>> As for examples?  I know well how to use itemlists.  I routinely
>>> encounter and routinely write pages of source code to do a few simple
>>> system service API calls, too.
>>>
>>> And the itemlist APIs can fail at even that upward-compatibility
>>> task, with fixed-length buffers being ubiquitous.  Which means a
>>> two-pass call, with added memory allocation and deallocation glue code.
>>>
>>> We all always get all of our memory allocation and memory
>>> deallocation entirely right, too.  I'm not the only one that's ever
>>> made mistakes here, whether leaks or missing access checks—itemlists
>>> are really fun across mode changes.  And I know I'm not alone here
>>> with these mistakes, having fixed various leaks and itemlist parsing
>>> written by other folks.   It's forty years in and we still don't have
>>> a freaking itemlist parser-generator?  Ah well, what I'm using
>>> elsewhere eliminates this mess, and is a whole lot less glue code for
>>> callers to write.
>
> [expurgated—deletia—clippage]
>
>> Ok, an item list:
>>
>>          Record Socket_Options             !  Socket characteristics
>>                  Word    Protocol%
>>                  String  Typ$=1
>>                  String  AF$=1
>>          End Record
>>
>>
>> So, Ok, lots of definitions, but, it's done once, and put in an
>> include file.  Then any program can use the include file.
>>
>>          DECLARE SOCKET_OPTIONS  SOCKOPT   !  Socket characteristics
>>
>> A simple variable definition then gives one an item list.
>>
>> 130     !************************************************
>>          !             Create Connection Socket
>>          !************************************************
>>
>>          SOCKOPT::PROTOCOL% = TCPIP$C_TCP                !  Socket
>> characteristic
>> s
>>          SOCKOPT::TYP$ = CHR$(TCPIP$C_STREAM)
>>          SOCKOPT::AF$ = CHR$(TCPIP$C_AF_INET)
>>
>>          Stat% = SYS$QIOW(       ,                       !  Event flag &
>>                                  CH% By Value,           !  VMS channel &
>>                                  IO$_SETMODE By Value,   !  Operation &
>>                                  IOSB::Stat%,            !  I/O status
>> block &
>>                                  ,                       !  AST routine &
>>                                  ,                       !  AST
>> parameter &
>>                                  SOCKOPT::PROTOCOL%,     !  P1 &
>>                                  ,                       !  P2 &
>>                                  ,                       !  P3 &
>>                                  ,                       !  P4 &
>>                                  ,                       !  P5 &
>>                                  )                       !  P6
>>
>>          If      ( Stat% And SS$_NORMAL ) = 0%
>>          Then    Call VMSERR( Stat% , E$ )
>>                  E$ = "Unable to queue create connection socket - " + E$
>>                  E% = -1%
>>                  SaveStat% = Stat%
>>                  GoTo Deassign_Channel
>>          End If
>>
>>          If      ( IOSB::Stat% And SS$_NORMAL ) = 0%
>>          Then    Call VMSERR( IOSB::Stat% , E$ )
>>                  E$ = "Unable to create connection socket - " + E$
>>                  E% = -1%
>>                  SaveStat% = IOSB::Stat%
>>                  GoTo Deassign_Channel
>>          End If
>>
>> One might notice that a large part of the code is in the error
>> handling.   Sorry, nobody is going to talk me out of that.  Assume
>> nothing. Expect anything.  Prepare for anything.
>>
>> Basically, one defines a RECORD / STRUCTURE.
>> Then declare a variable of that RECORD / STRUCTURE.
>> Set the pieces of the variable as needed.
>> Call the system service.
>> Handle the result.
>>
>> One note, the above code was extracted from a subprogram, so arguments
>> to the subprogram are included in the code.  Could be simpler without
>> that.  IOSB is another RECORD, not included above.
>>
>> Have I cluttered up c.o.v enough?
>
>
> You're not seeing it, David.

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

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.

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.

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

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