[Info-vax] VSI strategy for OpenVMS

[Arne Vajhøj]

On 9/13/2021 10:50 AM, Jan-Erik Söderholm wrote:
> Den 2021-09-13 kl. 15:38, skrev Arne Vajhøj:
>> On 9/13/2021 8:29 AM, chris wrote:
>>> VMS will need some sort of unix abstraction layer to make use of all
>>> the Linux and other os open source packages. Done right, it should
>>> make the porting task much easier.
>>
>> Compilers with support for latest language standards, runtime libraries
>> that provide what is expected today of any OS, VMS support in common
>> libraries will certainly help.
>>
>> But I doubt there is value in true Linux emulation (non-Linux Unix
>> is not relevant). It probably would have been relevant 15 years ago.
>> But I am not so sure about today.
>>
>> The industry trend is moving towards huge libraries that encapsulate
>> the OS and avoid OS specific calls in application code.
>>
>> Sure it is easier if those libraries can use the Linux code
>> on VMS, but applications should outnumber libraries by a few magnitudes.
>>
>> If someone really needs Linux then they will probably run Linux.
> 
> I think so too. And what VMS has to have is good support for messaging
> and other interoperational standards and tools.
> 
> Personally, I'd like to see an updated and supported IBM MQ client.
> Doesn't have to be a full MQ server, there is already an IBM WebSphere
> environment in the corporate IT map that has all that...

Message queues are certainly something relevant.

Note that it is really a matrix.

Message queue:
* IBM MQ
* AMQP standard
* STOMP standard
* OpenWire (Apache)
* Kafka

Language/technology:
* C/C++
* descriptor languages
* Python
* Java
* PHP

So we have:
* IBM MQ - C/C++ in old version
* AMQP - C/C++ (VSI)
* STOMP - C/C++ (open source that builds on VMS)
* AMQP - Python
* STOMP - Python (??)
* all - Java (pure Java client libs)

Anything missing?

Arne