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

[Arne Vajhøj]

On 6/25/2021 4:06 PM, Stephen Hoffman wrote:
> On 2021-06-25 14:30:08 +0000, Arne Vajhj said:
>> On 6/25/2021 9:12 AM, Dave Froble wrote:
>>> On 6/25/2021 4:48 AM, Jan-Erik Söderholm wrote:
>>>> Den 2021-06-25 kl. 00:38, skrev Dave Froble:
>>>>> Current thoughts are a single listener that validates requests, 
>>>>> accepts the connection, and passes it off to a worker process, then 
>>>>> drops it's own connection to the socket.  Involves some 
>>>>> inter-process communications.  Listener might get rather busy, but 
>>>>> will spend little time on each request.

> This is where message queuing can be handy, but that tends to shift the 
> underlying app design around somewhat.

If async is OK *and* of the infrastructure footprint of the message
queue is OK, then that could be a great solution.

client_xxx put task in /queue/precheck
listener read task from /queue/precheck
     ok => put task in /queue/task
     notok => put error in /queue/client_xxx
worker read task from /queue/task, process and put result in 
/queue/client_xxx

>>> WASD is  a "jack of all trades" type of app, and does that reasonably 
>>> well.  What we require is a specialist, for various reasons.
>>
>>> One size does not fit all.
>>
>> 95% is HTTP today, but that leaves 5% for everything else.
> 
> HTTPS is very common, yes. Downside on OpenVMS is that REST support 
> stinks in most of the established OpenVMS languages and frameworks, and 
> support is ~nonexistent within OpenVMS itself.

In all fairness REST support stinks in those languages on other
platforms as well.

The REST world is dominated by languages less than 30 years old.

But Java, Python and PHP are available on VMS.

>> Non-HTTP approaches are still seen.
> 
> Particularly for established app activities, and for cases where REST 
> doesn't fit well.
> 
>> If you have a requirement to be easily accessible from multiple 
>> languages then then you could look at Thrift.
> 
> Which would entail porting Apache Thrift to OpenVMS, of course.

For the language used. Which may be a small or big task depending
on what language.

>> I still believe that a multi-threaded listener doing IPC with workers 
>> is the right design.
> 
> OpenVMS doesn't do threads all that well.

Doesn't pthreads do what it is supposed to do?

> OpenVMS does offer KP Threads, but I've not met production apps mixing 
> KP threads and BASIC.  It's likely possible, just not something I've 
> seen or used from BASIC.

Why not pthreads?

Standard.

> OpenVMS threading support here is pre-millennial, in terms of frameworks 
> and language support. Aside from some existing underpinnings; KP 
> Threads, or ASTs with two threads, one core. Or pthreads for C and C++ 
> and (presumably) Rust if/when.
> 
> Which means more than a few cases of writing interlocked queue 
> message-passing, or other similar home-grown mechanisms.
> 
> libdispatch/GCD or similar multi-threading support never made it over, 
> short of porting or re-creating it yourself.

Nothing wrong with a basic thread model.

It is not new, but its usage are quite well-known.

Need to sync? pthread_mutex_t, pthread_mutex_lock
and pthread_mutex_unlock.

Arne