[Info-vax] OpenVMS Development Annoyances

[Dave Froble]

On 5/6/2019 8:27 PM, seasoned_geek wrote:
> 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.
>>
>
> You still didn't say what language you are using. I'm guessing C given your description. These things are much easier in BASIC. C on OpenVMS is just nasty. Don't blame the OS for that.
>
> @Dave, why don't you post a few of your system service calls in BASIC?
>

What?  You want me to help Steve in his arguments?

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?

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