[Info-vax] Listeners in VMS Basic, was: Re: Integrity iLO Configuration?

[Dave Froble]

On 7/1/2021 2:36 PM, Arne Vajhøj wrote:
> On 7/1/2021 10:40 AM, Dave Froble wrote:
>> On 7/1/2021 10:17 AM, Arne Vajhøj wrote:
>>> On 7/1/2021 8:16 AM, Bill Gunshannon wrote:
>>>> On 7/1/21 8:12 AM, Simon Clubley wrote:
>>>>> For David, if it worked 30 years ago, then its good enough for today.
>>>>> :-)
>>>>
>>>> In too many cases, that is quite true.  Change for changes sake
>>>> is not an improvement.  And change to increase the ego of some
>>>> academic is even worse.
>>>
>>> Technology constantly makes progress.
>>>
>>> Problem is to know what provides significant benefits versus
>>> what is just nice to have and to know what will become long term viable
>>> and what will turn out to be a dead end.
>>
>> If something has been working successfully for 30 years, and is still
>> working successfully, would that not rule out any "dead ends"?
>
> It is proof that the right choices was made 30 years ago.
>
> It does not guarantee anything about the future.
>
> But being right in the past should make being right in the future
> slightly more likely.
>
>> I've looked at some "progress".  Many times I've then asked, why is
>> all the bloat being used?  As an example, there are things that are
>> piled on top of a socket connection, instead of just using the socket
>> connection.   What do they achieve, other than slowing down the entire
>> process? They are not less work for the programmer, just lots of extra
>> code.
>
> I am not sure what you are talking about.
>
> Adding SSL on top of sockets tend to add more code, but it also
> provides something.
>
> Other than that then network API's seems to get simpler
> over time.
>
>> I'm not saying there cannot be better methods, I'm saying that it
>> really must be better, or, it's not really progress.
>
> Yep.
>
>> As for Arne's example, whatever it does, it sure is not maintainable.
>> If code is not maintainable, what good is it?
>
> It is an rtificial piece of code as it basically does a very
> trivial operation (sum an array) 5 different ways and time them.
>
> But the basic elements should be relative easy
> ]understandable by millions of developers.
>
> Basically it contains:
> * Basic syntax
> * OOP
> * arrays
> * calls
> * basic thread usage
> * basic thread pool usage
> * fluent API syntax
>
> You noted the lack of comments, but there really should
> only be a few explaining what the classes and methods do.
> The rest is RTFM stuff.

All code should explain itself.  The manuals are there to define 
specifics, such as the arguments in a QIO call.  But the program 
comments should explain why the QIO is being called.

There wasn't even one comment in your example, to at least explain what 
the code would attempt to do.  Making someone puzzle out such is not a 
good practice.  Actually, it is a very bad practice.

Code should be maintainable.  To be such, there is no such thing as too 
many comments.

An example of how I write code.

at the top of a subprogram:

         !************************************************
         !       This subprogram will set up TCP/IP sockets to allow
         !       itself to connect to a service, send a message, and
         !       receive a response.
         !
         !       The timeout AST is queued prior to any network
         !       activity.  It's left on until the routine exits.
         !       The concept is that the user doesn't really care
         !       why the routine timed out.  The routine has a
         !       specified amount of time to complete it's task,
         !       and then the task is aborted.
         !
         !************************************************

useful information:

         ! Parameter list:
         !
         !       IP.ADR$         - IP address string
         !       PORT%           - WORD port number
         !       SEND.MSG$       - Message to send (max 4096 bytes)
         !       RECV.MSG$       - Return message target (max 4096 bytes)
         !       W%              - Seconds to wait for response
         !       E$              - Error message
         !       COMP.STAT%      - WORD Completion status

what you're going to do:

      !************************************************
         !             Create Connection Socket
         !************************************************

         SOCKOPT::PROTOCOL% = TCPIP$C_TCP                !  Socket 
characteristi^
         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

you might notice the arguments on separate lines, to allow documentation 
of each argument

you might also notice that I could have better explained the passing of 
the item list by ref in the P1 argument

and of course the mandatory error testing:

         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

Things like the above are the minimum acceptable, to me, and, more would 
be better.

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