Dear VMS friends,

The recent "Rendez-vous autour de VMS" event held by the VMSgenerations
French club took a new format, more technical and followed by a live
demonstration.

The session was dedicated to VMS integration with other environments and
generated a lot of interest from the attendees. We showed directions for
VMS application modernization based on real life consultants experiences
at multiple customer sites

You can find a session report (French and English), slides and video
recordings of the main topics on our site :
https://www.vmsgenerations.fr/rdv-15-nov-2022/
We remain available for any question or contribution. Email us at
contact@vmsgenerations.fr .

The VMSgeneration board

https://www.vmsgenerations.fr

--
Cet e-mail a été vérifié par le logiciel antivirus d'Avast.
www.avast.com

On 12/1/2022 9:16 AM, VMSgenerations working group wrote:
> The recent "Rendez-vous autour de VMS" event held by the VMSgenerations
> French club took a new format, more technical and followed by a live
> demonstration.
>
> The session was dedicated to VMS integration with other environments and
> generated a lot of interest from the attendees. We showed directions for
> VMS application modernization based on real life consultants experiences
> at multiple customer sites
>
> You can find a session report (French and English), slides and video
> recordings of the main topics on our site :
> https://www.vmsgenerations.fr/rdv-15-nov-2022/

Good job.

I think the french VMS user community is a great
example for the rest of us.

Arne

On Thursday, December 1, 2022 at 10:40:44 AM UTC-5, Arne Vajhøj wrote:
> On 12/1/2022 9:16 AM, VMSgenerations working group wrote:
> > The recent "Rendez-vous autour de VMS" event held by the VMSgenerations
> > French club took a new format, more technical and followed by a live
> > demonstration.
> >
> > The session was dedicated to VMS integration with other environments and
> > generated a lot of interest from the attendees. We showed directions for
> > VMS application modernization based on real life consultants experiences
> > at multiple customer sites
> >
> > You can find a session report (French and English), slides and video
> > recordings of the main topics on our site :
> > https://www.vmsgenerations.fr/rdv-15-nov-2022/
> Good job.
>
> I think the french VMS user community is a great
> example for the rest of us.
>
> Arne

I think it is great whenever any group supports OpenVMS

Neil Rieck
Waterloo, Ontario, Canada.
http://neilrieck.net/OpenVMS-Programmers-Corner.html

On Thursday, December 1, 2022 at 9:16:43 AM UTC-5, VMSgenerations working group wrote:
> Dear VMS friends,
>
> The recent "Rendez-vous autour de VMS" event held by the VMSgenerations
> French club took a new format, more technical and followed by a live
> demonstration.
>
> The session was dedicated to VMS integration with other environments and
> generated a lot of interest from the attendees. We showed directions for
> VMS application modernization based on real life consultants experiences
> at multiple customer sites
>
> You can find a session report (French and English), slides and video
> recordings of the main topics on our site :
> https://www.vmsgenerations.fr/rdv-15-nov-2022/
:

Thanks Jean-François Piéronne and friends. I listened to some of the témoignages (Christian, Rémi ) and they proved interesting. Fun challenge to motivate both young developers and 'old farts - 40 years in the business' in these projects. Also interesting to hear/see was the importance of RabbitMQ.
Keep up the good work!
Hein.

On 12/3/2022 1:28 AM, Hein RMS van den Heuvel wrote:
> On Thursday, December 1, 2022 at 9:16:43 AM UTC-5, VMSgenerations working group wrote:
>> The recent "Rendez-vous autour de VMS" event held by the VMSgenerations
>> French club took a new format, more technical and followed by a live
>> demonstration.
>>
>> The session was dedicated to VMS integration with other environments and
>> generated a lot of interest from the attendees. We showed directions for
>> VMS application modernization based on real life consultants experiences
>> at multiple customer sites
>>
>> You can find a session report (French and English), slides and video
>> recordings of the main topics on our site :
>> https://www.vmsgenerations.fr/rdv-15-nov-2022/
>
> Thanks Jean-François Piéronne and friends. I listened to some of the
> témoignages (Christian, Rémi ) and they proved interesting. Fun
> challenge to motivate both young developers and 'old farts - 40 years
> in the business' in these projects. Also interesting to hear/see was
> the importance of RabbitMQ.
Message queues has become a part of most new solutions today.

There are 3 big players in the message queue server market:
- RabbitMQ
- ActiveMQ/ArtemisMQ
- Kafka

Note 1: Kafka is not a traditional message queue server, but it is
a relevant alternative in some cases.

Note 2: various commercial offerings from IBM, Oracle, MS
etc. still exist but the open source ones dominate the
market.

But in many ways the choice of server is not so important
as standard protocols has been created to talk to to those
servers: AMQP, STOMP and MQTT.

Arne

On 12/3/2022 9:16 AM, Arne Vajhøj wrote:
> On 12/3/2022 1:28 AM, Hein RMS van den Heuvel wrote:
>> Also interesting to hear/see was
>> the importance of RabbitMQ.
> Message queues has become a part of most new solutions today.
>
> There are 3 big players in the message queue server market:
> - RabbitMQ
> - ActiveMQ/ArtemisMQ
> - Kafka
>
> Note 1: Kafka is not a traditional message queue server, but it is
> a relevant alternative in some cases.
>
> Note 2: various commercial offerings from IBM, Oracle, MS
> etc. still exist but the open source ones dominate the
> market.
>
> But in many ways the choice of server is not so important
> as standard protocols has been created to talk to to those
> servers: AMQP, STOMP and MQTT.

VSI offers:

ActiveMQ server + JVM client (JMS) -
https://vmssoftware.com/products/activemq/

Mosquito (MQTT) server - https://vmssoftware.com/products/mosquitto/

RabbitMQ native client (librabbitmq) that I suspect will work with any
server talking AMQP - https://vmssoftware.com/products/librabbitmq/

Client for MQTT protocol - https://vmssoftware.com/products/paho-c/

Outside of that:

JFP VMS Python (I have not checked VSI VMS Python) comes with
an AMQP module and it is possible to get the standard stomp
module working.

RabbitMQ JVM client should work on VMS if the Java version is new enough.

And for those wanting native access then there exist open source
C code for STOMP protocol (plus I have created VMS wrappers for
it - https://www.vajhoej.dk/arne/opensource/vms/ grab the vmspstomp
library).

So VMS does have something in this area.

Arne

On 12/3/2022 9:38 AM, Arne Vajhøj wrote:
> VSI offers:
>
> ActiveMQ server + JVM client (JMS) -
> https://vmssoftware.com/products/activemq/
>
> Mosquito (MQTT) server - https://vmssoftware.com/products/mosquitto/
>
> RabbitMQ native client (librabbitmq) that I suspect will work with any
> server talking AMQP - https://vmssoftware.com/products/librabbitmq/
>
> Client for MQTT protocol - https://vmssoftware.com/products/paho-c/
>
> Outside of that:
>
> JFP VMS Python (I have not checked VSI VMS Python) comes with
> an AMQP module and it is possible to get the standard stomp
> module working.
>
> RabbitMQ JVM client should work on VMS if the Java version is new enough.
>
> And for those wanting native access then there exist open source
> C code for STOMP protocol (plus I have created VMS wrappers for
> it - https://www.vajhoej.dk/arne/opensource/vms/ grab the vmspstomp
> library).
>
> So VMS does have something in this area.

Above list is probably not complete, but it is what I am
aware of or could find quickly.

Arne

Den 2022-12-03 kl. 15:38, skrev Arne Vajhøj:
> On 12/3/2022 9:16 AM, Arne Vajhøj wrote:
>> On 12/3/2022 1:28 AM, Hein RMS van den Heuvel wrote:
>>>                           Also interesting to hear/see was
>>> the importance of RabbitMQ.
>> Message queues has become a part of most new solutions today.
>>
>> There are 3 big players in the message queue server market:
>> - RabbitMQ
>> - ActiveMQ/ArtemisMQ
>> - Kafka
>>
>> Note 1: Kafka is not a traditional message queue server, but it is
>> a relevant alternative in some cases.
>>
>> Note 2: various commercial offerings from IBM, Oracle, MS
>> etc. still exist but the open source ones dominate the
>> market.
>>
>> But in many ways the choice of server is not so important
>> as standard protocols has been created to talk to to those
>> servers: AMQP, STOMP and MQTT.
>
> VSI offers:
>
> ActiveMQ server + JVM client (JMS) -
> https://vmssoftware.com/products/activemq/
>
> Mosquito (MQTT) server - https://vmssoftware.com/products/mosquitto/
>
> RabbitMQ native client (librabbitmq) that I suspect will work with any
> server talking AMQP - https://vmssoftware.com/products/librabbitmq/
>
> Client for MQTT protocol - https://vmssoftware.com/products/paho-c/
>
> Outside of that:
>
> JFP VMS Python (I have not checked VSI VMS Python) comes with
> an AMQP module and it is possible to get the standard stomp
> module working.
>
> RabbitMQ JVM client should work on VMS if the Java version is new enough.
>
> And for those wanting native access then there exist open source
> C code for STOMP protocol (plus I have created VMS wrappers for
> it - https://www.vajhoej.dk/arne/opensource/vms/ grab the vmspstomp
> library).
>
> So VMS does have something in this area.
>
> Arne
>

Which of these (if any) has a VMS only complete solution?
That is, that doesn't need some "external" Linux (or other)
based server component?

If I just want to have a message based solution for communication
between different native VMS applications, I do not want to be
dependent on some other system/environment.

Yes, mail boxes works quite nice, but there are some issues with
having multiple readers on a mailbox. And you can only "buffer" as
much as our mailbox buffer has room for.

On 12/3/2022 10:04 AM, Jan-Erik Söderholm wrote:
> Den 2022-12-03 kl. 15:38, skrev Arne Vajhøj:
>> VSI offers:
>>
>> ActiveMQ server + JVM client (JMS) -
>> https://vmssoftware.com/products/activemq/
>>
>> Mosquito (MQTT) server - https://vmssoftware.com/products/mosquitto/
>>
>> RabbitMQ native client (librabbitmq) that I suspect will work with any
>> server talking AMQP - https://vmssoftware.com/products/librabbitmq/
>>
>> Client for MQTT protocol - https://vmssoftware.com/products/paho-c/
>>
>> Outside of that:
>>
>> JFP VMS Python (I have not checked VSI VMS Python) comes with
>> an AMQP module and it is possible to get the standard stomp
>> module working.
>>
>> RabbitMQ JVM client should work on VMS if the Java version is new enough.
>>
>> And for those wanting native access then there exist open source
>> C code for STOMP protocol (plus I have created VMS wrappers for
>> it - https://www.vajhoej.dk/arne/opensource/vms/ grab the vmspstomp
>> library).
>>
>> So VMS does have something in this area.
>
> Which of these (if any) has a VMS only complete solution?
> That is, that doesn't need some "external" Linux (or other)
> based server component?

Client is not a problem. Almost any programming language for
application any server will do today due to the standard
protocols. In https://www.vajhoej.dk/arne/articles/vmsipc.html#mq
I got Java, Jython, C, Python, Fortran, Pascal, Cobol and
Basic talking to ActiveMQ.

Server is the issue.

As far as I know then RabbitMQ server does not run on VMS. Erlang
is available for VMS, but not RabbitMQ (RabbitMQ is written
in Erlang).

VSI has ActiveMQ server for VMS I64, but not for VMS Alpha
(I assume the reason is that VMS I64 got Java 8 while VMS Alpha
only got Java 5).

VSI has the Mosqito server for both VMS I64 and VMS Alpha.
But MQTT is really intended for thingies-server communication
not for server-server communication, so I don't know how
well it will fit your use case.

> If I just want to have a message based solution for communication
> between different native VMS applications, I do not want to be
> dependent on some other system/environment.

If the load is not big enough to require a separate server
then that makes sense.

> Yes, mail boxes works quite nice, but there are some issues with
> having multiple readers on a mailbox. And you can only "buffer" as
> much as our mailbox buffer has room for.

Message queues are a huge improvement compared to mailboxes.

Arne

On 12/3/2022 10:36 AM, Arne Vajhøj wrote:
> VSI has ActiveMQ server for VMS I64, but not for VMS Alpha
> (I assume the reason is that VMS I64 got Java 8 while VMS Alpha
> only got Java 5).

It could be interesting to dig up an old version of ActiveMQ that
run on Java 5 and see it it would work on VMS Alpha.

Objectively ActiveMQ/ArtemisMQ is not better than RabbitMQ - it
is more like a GM vs Ford or VW vs Toyota thing. But I happen
to like it.

A cute thing with ActiveMQ/ArtemisMQ is that even though it
default to a custom storage for persisted queues, then it can
be configured to use a relational database (via JDBC driver)
as storage for persisted queues.

Arne

On 12/3/2022 9:39 AM, Arne Vajhøj wrote:
> On 12/3/2022 9:38 AM, Arne Vajhøj wrote:
>> VSI offers:
>>
>> ActiveMQ server + JVM client (JMS) - https://vmssoftware.com/products/activemq/
>>
>> Mosquito (MQTT) server - https://vmssoftware.com/products/mosquitto/
>>
>> RabbitMQ native client (librabbitmq) that I suspect will work with any server
>> talking AMQP - https://vmssoftware.com/products/librabbitmq/
>>
>> Client for MQTT protocol - https://vmssoftware.com/products/paho-c/
>>
>> Outside of that:
>>
>> JFP VMS Python (I have not checked VSI VMS Python) comes with
>> an AMQP module and it is possible to get the standard stomp
>> module working.
>>
>> RabbitMQ JVM client should work on VMS if the Java version is new enough.
>>
>> And for those wanting native access then there exist open source
>> C code for STOMP protocol (plus I have created VMS wrappers for
>> it - https://www.vajhoej.dk/arne/opensource/vms/ grab the vmspstomp
>> library).
>>
>> So VMS does have something in this area.
>
> Above list is probably not complete, but it is what I am
> aware of or could find quickly.
>
> Arne

Would you like an 1980s era message queue product to evaluate?

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

On 12/3/2022 10:04 AM, Jan-Erik Söderholm wrote:
> Den 2022-12-03 kl. 15:38, skrev Arne Vajhøj:
>> On 12/3/2022 9:16 AM, Arne Vajhøj wrote:
>>> On 12/3/2022 1:28 AM, Hein RMS van den Heuvel wrote:
>>>> Also interesting to hear/see was
>>>> the importance of RabbitMQ.
>>> Message queues has become a part of most new solutions today.
>>>
>>> There are 3 big players in the message queue server market:
>>> - RabbitMQ
>>> - ActiveMQ/ArtemisMQ
>>> - Kafka
>>>
>>> Note 1: Kafka is not a traditional message queue server, but it is
>>> a relevant alternative in some cases.
>>>
>>> Note 2: various commercial offerings from IBM, Oracle, MS
>>> etc. still exist but the open source ones dominate the
>>> market.
>>>
>>> But in many ways the choice of server is not so important
>>> as standard protocols has been created to talk to to those
>>> servers: AMQP, STOMP and MQTT.
>>
>> VSI offers:
>>
>> ActiveMQ server + JVM client (JMS) - https://vmssoftware.com/products/activemq/
>>
>> Mosquito (MQTT) server - https://vmssoftware.com/products/mosquitto/
>>
>> RabbitMQ native client (librabbitmq) that I suspect will work with any server
>> talking AMQP - https://vmssoftware.com/products/librabbitmq/
>>
>> Client for MQTT protocol - https://vmssoftware.com/products/paho-c/
>>
>> Outside of that:
>>
>> JFP VMS Python (I have not checked VSI VMS Python) comes with
>> an AMQP module and it is possible to get the standard stomp
>> module working.
>>
>> RabbitMQ JVM client should work on VMS if the Java version is new enough.
>>
>> And for those wanting native access then there exist open source
>> C code for STOMP protocol (plus I have created VMS wrappers for
>> it - https://www.vajhoej.dk/arne/opensource/vms/ grab the vmspstomp
>> library).
>>
>> So VMS does have something in this area.
>>
>> Arne
>>
>
> Which of these (if any) has a VMS only complete solution?
> That is, that doesn't need some "external" Linux (or other)
> based server component?
>
> If I just want to have a message based solution for communication
> between different native VMS applications, I do not want to be
> dependent on some other system/environment.
>
> Yes, mail boxes works quite nice, but there are some issues with
> having multiple readers on a mailbox. And you can only "buffer" as
> much as our mailbox buffer has room for.
>
>

So, would you like a copy of TQUMAN to evaluate and use? Actually, a 1970s era
product developed on RSTS/E, and moved to VMS. Hey, the price is right.

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

Den 2022-12-03 kl. 18:55, skrev Dave Froble:
> On 12/3/2022 10:04 AM, Jan-Erik Söderholm wrote:
>> Den 2022-12-03 kl. 15:38, skrev Arne Vajhøj:
>>> On 12/3/2022 9:16 AM, Arne Vajhøj wrote:
>>>> On 12/3/2022 1:28 AM, Hein RMS van den Heuvel wrote:
>>>>>                           Also interesting to hear/see was
>>>>> the importance of RabbitMQ.
>>>> Message queues has become a part of most new solutions today.
>>>>
>>>> There are 3 big players in the message queue server market:
>>>> - RabbitMQ
>>>> - ActiveMQ/ArtemisMQ
>>>> - Kafka
>>>>
>>>> Note 1: Kafka is not a traditional message queue server, but it is
>>>> a relevant alternative in some cases.
>>>>
>>>> Note 2: various commercial offerings from IBM, Oracle, MS
>>>> etc. still exist but the open source ones dominate the
>>>> market.
>>>>
>>>> But in many ways the choice of server is not so important
>>>> as standard protocols has been created to talk to to those
>>>> servers: AMQP, STOMP and MQTT.
>>>
>>> VSI offers:
>>>
>>> ActiveMQ server + JVM client (JMS) -
>>> https://vmssoftware.com/products/activemq/
>>>
>>> Mosquito (MQTT) server - https://vmssoftware.com/products/mosquitto/
>>>
>>> RabbitMQ native client (librabbitmq) that I suspect will work with any
>>> server
>>> talking AMQP - https://vmssoftware.com/products/librabbitmq/
>>>
>>> Client for MQTT protocol - https://vmssoftware.com/products/paho-c/
>>>
>>> Outside of that:
>>>
>>> JFP VMS Python (I have not checked VSI VMS Python) comes with
>>> an AMQP module and it is possible to get the standard stomp
>>> module working.
>>>
>>> RabbitMQ JVM client should work on VMS if the Java version is new enough.
>>>
>>> And for those wanting native access then there exist open source
>>> C code for STOMP protocol (plus I have created VMS wrappers for
>>> it - https://www.vajhoej.dk/arne/opensource/vms/ grab the vmspstomp
>>> library).
>>>
>>> So VMS does have something in this area.
>>>
>>> Arne
>>>
>>
>> Which of these (if any) has a VMS only complete solution?
>> That is, that doesn't need some "external" Linux (or other)
>> based server component?
>>
>> If I just want to have a message based solution for communication
>> between different native VMS applications, I do not want to be
>> dependent on some other system/environment.
>>
>> Yes, mail boxes works quite nice, but there are some issues with
>> having multiple readers on a mailbox. And you can only "buffer" as
>> much as our mailbox buffer has room for.
>>
>>
>
> So, would you like a copy of TQUMAN to evaluate and use?  Actually, a 1970s
> era product developed on RSTS/E, and moved to VMS.  Hey, the price is right.
>

I have managed DMQ (DEC MessageQ) and developed applications for
it way back in time. I liked that and it was really nice.

So my main requirements are:
- Not dependent on having another system for the server part.
- Not having *anything* to do with Java.

Java might have been a good idea, theoretically, but I have seen
too many systems and applications go down by performance or other
technical issues. So no, I'm just not interested.

I googled TQUMAN and it only (I think) come up with this:
https://groups.google.com/g/comp.os.vms/c/xnGcznmuLE4

I cannot tell from that if I want to look at it or not... :-)

On 12/3/2022 4:50 PM, Jan-Erik Söderholm wrote:
> Den 2022-12-03 kl. 18:55, skrev Dave Froble:
>> On 12/3/2022 10:04 AM, Jan-Erik Söderholm wrote:
>>> Den 2022-12-03 kl. 15:38, skrev Arne Vajhøj:
>>>> On 12/3/2022 9:16 AM, Arne Vajhøj wrote:
>>>>> On 12/3/2022 1:28 AM, Hein RMS van den Heuvel wrote:
>>>>>> Also interesting to hear/see was
>>>>>> the importance of RabbitMQ.
>>>>> Message queues has become a part of most new solutions today.
>>>>>
>>>>> There are 3 big players in the message queue server market:
>>>>> - RabbitMQ
>>>>> - ActiveMQ/ArtemisMQ
>>>>> - Kafka
>>>>>
>>>>> Note 1: Kafka is not a traditional message queue server, but it is
>>>>> a relevant alternative in some cases.
>>>>>
>>>>> Note 2: various commercial offerings from IBM, Oracle, MS
>>>>> etc. still exist but the open source ones dominate the
>>>>> market.
>>>>>
>>>>> But in many ways the choice of server is not so important
>>>>> as standard protocols has been created to talk to to those
>>>>> servers: AMQP, STOMP and MQTT.
>>>>
>>>> VSI offers:
>>>>
>>>> ActiveMQ server + JVM client (JMS) - https://vmssoftware.com/products/activemq/
>>>>
>>>> Mosquito (MQTT) server - https://vmssoftware.com/products/mosquitto/
>>>>
>>>> RabbitMQ native client (librabbitmq) that I suspect will work with any server
>>>> talking AMQP - https://vmssoftware.com/products/librabbitmq/
>>>>
>>>> Client for MQTT protocol - https://vmssoftware.com/products/paho-c/
>>>>
>>>> Outside of that:
>>>>
>>>> JFP VMS Python (I have not checked VSI VMS Python) comes with
>>>> an AMQP module and it is possible to get the standard stomp
>>>> module working.
>>>>
>>>> RabbitMQ JVM client should work on VMS if the Java version is new enough.
>>>>
>>>> And for those wanting native access then there exist open source
>>>> C code for STOMP protocol (plus I have created VMS wrappers for
>>>> it - https://www.vajhoej.dk/arne/opensource/vms/ grab the vmspstomp
>>>> library).
>>>>
>>>> So VMS does have something in this area.
>>>>
>>>> Arne
>>>>
>>>
>>> Which of these (if any) has a VMS only complete solution?
>>> That is, that doesn't need some "external" Linux (or other)
>>> based server component?
>>>
>>> If I just want to have a message based solution for communication
>>> between different native VMS applications, I do not want to be
>>> dependent on some other system/environment.
>>>
>>> Yes, mail boxes works quite nice, but there are some issues with
>>> having multiple readers on a mailbox. And you can only "buffer" as
>>> much as our mailbox buffer has room for.
>>>
>>>
>>
>> So, would you like a copy of TQUMAN to evaluate and use? Actually, a 1970s
>> era product developed on RSTS/E, and moved to VMS. Hey, the price is right.
>>
>
> I have managed DMQ (DEC MessageQ) and developed applications for
> it way back in time. I liked that and it was really nice.
>
> So my main requirements are:
> - Not dependent on having another system for the server part.
> - Not having *anything* to do with Java.
>
> Java might have been a good idea, theoretically, but I have seen
> too many systems and applications go down by performance or other
> technical issues. So no, I'm just not interested.
>
> I googled TQUMAN and it only (I think) come up with this:
> https://groups.google.com/g/comp.os.vms/c/xnGcznmuLE4
>
> I cannot tell from that if I want to look at it or not... :-)
>
>

Ok, I'll first try to describe the app. If there is interest, I will insure it
can be used outside the environment we've normally used the app, and make the
code available to anyone who wants to evaluate and/or use it.

A queue file is used to both describe the queues in use, and contain the actual
messages. A set of routines exist to use VMS mailboxes to set up the capability
to receive messages and send messages.

A maintenance program is used to initiate a queue file, to list current
messages, to add messages to a queue, and other general maintenance.

An operations program is used to run detached, receive messages to add to a
specific queue, and send a queue message when requested by any program that uses
one or more queues.

Usage is limited to a single VMS system, no networking involved.

If there is interest, I will need to do a bit of work. Might be interesting,
seeing how old the message application now is.

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

On 3/12/2022 10:16 pm, Arne Vajhøj wrote:
> On 12/3/2022 1:28 AM, Hein RMS van den Heuvel wrote:
>> On Thursday, December 1, 2022 at 9:16:43 AM UTC-5, VMSgenerations
>> working group wrote:
>>> The recent "Rendez-vous autour de VMS" event held by the
>>> VMSgenerations French club took a new format, more technical and
>>> followed by a live demonstration.
>>>
>>> The session was dedicated to VMS integration with other
>>> environments and generated a lot of interest from the attendees.
>>> We showed directions for VMS application modernization based on
>>> real life consultants experiences at multiple customer sites
>>>
>>> You can find a session report (French and English), slides and
>>> video recordings of the main topics on our site :
>>> https://www.vmsgenerations.fr/rdv-15-nov-2022/
>>
>> Thanks Jean-François Piéronne and friends. I listened to some of
>> the témoignages (Christian, Rémi ) and they proved interesting.
>> Fun challenge to motivate both young developers and 'old farts - 40
>> years in the business' in these projects. Also interesting to
>> hear/see was the importance of RabbitMQ.
> Message queues has become a part of most new solutions today.
>
> There are 3 big players in the message queue server market: -
> RabbitMQ - ActiveMQ/ArtemisMQ - Kafka
>
> Note 1: Kafka is not a traditional message queue server, but it is a
> relevant alternative in some cases.
>
> Note 2: various commercial offerings from IBM, Oracle, MS etc. still
> exist but the open source ones dominate the market.
>
> But in many ways the choice of server is not so important as standard
> protocols has been created to talk to to those servers: AMQP, STOMP
> and MQTT.
>
> Arne
>
>

Personally, I see message queues as a 90's solution. Same with ESBs.

Speaking of (TIBCO) Rendezvous :-)

Isn't GraphQL the latest?

On 12/3/2022 10:16 PM, Richard Maher wrote:
> On 3/12/2022 10:16 pm, Arne Vajhøj wrote:
>> Message queues has become a part of most new solutions today.
>>
>> There are 3 big players in the message queue server market: -
>> RabbitMQ - ActiveMQ/ArtemisMQ - Kafka
>>
>> Note 1: Kafka is not a traditional message queue server, but it is a
>> relevant alternative in some cases.
>>
>> Note 2: various commercial offerings from IBM, Oracle, MS etc. still
>> exist but the open source ones dominate the market.
>>
>> But in many ways the choice of server is not so important as standard
>> protocols has been created to talk to to those servers: AMQP, STOMP
>> and MQTT.
>
> Personally, I see message queues as a 90's solution.

ActiveMQ is from 2004, RabbitMQ is from 2007 and Kafka is from 2011.

:-)

> Same with ESBs.

The big IBM/Oracle/MS/JBoss/whoever ESB's sold well up in the 00's.

But they never delivered what they promised.

But simple message queues survived.

> Speaking of (TIBCO) Rendezvous :-)

Good one.

> Isn't GraphQL the latest?

I don't see how that relates to message queues or ESB's.

Arne

On 12/3/2022 10:27 PM, Arne Vajhøj wrote:
> On 12/3/2022 10:16 PM, Richard Maher wrote:
>> On 3/12/2022 10:16 pm, Arne Vajhøj wrote:
>>> Message queues has become a part of most new solutions today.
>>>
>>> There are 3 big players in the message queue server market: -
>>> RabbitMQ - ActiveMQ/ArtemisMQ - Kafka
>>>
>>> Note 1: Kafka is not a traditional message queue server, but it is a
>>> relevant alternative in some cases.
>>>
>>> Note 2: various commercial offerings from IBM, Oracle, MS etc. still
>>> exist but the open source ones dominate the market.
>>>
>>> But in many ways the choice of server is not so important as standard
>>> protocols has been created to talk to to those servers: AMQP, STOMP
>>> and MQTT.
>>
>> Personally, I see message queues as a 90's solution.
>
> ActiveMQ is from 2004, RabbitMQ is from 2007 and Kafka is from 2011.
>
> :-)
>
>>                                                       Same with ESBs.
>
> The big IBM/Oracle/MS/JBoss/whoever ESB's sold well up in the 00's.
>
> But they never delivered what they promised.
>
> But simple message queues survived.

Small and medium size solutions use ActiveMQ/ArtemisMQ or RabbitMQ
(probably mostly depending on whether they prefer product names that
start with J or not).

Large size solutions go for Kafka. Kafka is really the only
option for extreme workloads.

A few of the big Kafka users are:

LinkedIn - 100 clusters with 4000 nodes processing 7 trillion
messages per day (2019)

Pinterest - 50 clusters with 3000 nodes and a peak processing
of 40 million messages per second (2021).

Arne

Jan-Erik Söderholm explained on 03/12/2022 :
> Den 2022-12-03 kl. 15:38, skrev Arne Vajhøj:
>> On 12/3/2022 9:16 AM, Arne Vajhøj wrote:
>>> On 12/3/2022 1:28 AM, Hein RMS van den Heuvel wrote:
>>>>                           Also interesting to hear/see was
>>>> the importance of RabbitMQ.
>>> Message queues has become a part of most new solutions today.
>>>
>>> There are 3 big players in the message queue server market:
>>> - RabbitMQ
>>> - ActiveMQ/ArtemisMQ
>>> - Kafka
>>>
>>> Note 1: Kafka is not a traditional message queue server, but it is
>>> a relevant alternative in some cases.
>>>
>>> Note 2: various commercial offerings from IBM, Oracle, MS
>>> etc. still exist but the open source ones dominate the
>>> market.
>>>
>>> But in many ways the choice of server is not so important
>>> as standard protocols has been created to talk to to those
>>> servers: AMQP, STOMP and MQTT.
>>
>> VSI offers:
>>
>> ActiveMQ server + JVM client (JMS) -
>> https://vmssoftware.com/products/activemq/
>>
>> Mosquito (MQTT) server - https://vmssoftware.com/products/mosquitto/
>>
>> RabbitMQ native client (librabbitmq) that I suspect will work with any
>> server talking AMQP - https://vmssoftware.com/products/librabbitmq/
>>
>> Client for MQTT protocol - https://vmssoftware.com/products/paho-c/
>>
>> Outside of that:
>>
>> JFP VMS Python (I have not checked VSI VMS Python) comes with
>> an AMQP module and it is possible to get the standard stomp
>> module working.
>>
>> RabbitMQ JVM client should work on VMS if the Java version is new enough.
>>
>> And for those wanting native access then there exist open source
>> C code for STOMP protocol (plus I have created VMS wrappers for
>> it - https://www.vajhoej.dk/arne/opensource/vms/ grab the vmspstomp
>> library).
>>
>> So VMS does have something in this area.
>>
>> Arne
>>
>
> Which of these (if any) has a VMS only complete solution?
> That is, that doesn't need some "external" Linux (or other)
> based server component?
>
> If I just want to have a message based solution for communication
> between different native VMS applications, I do not want to be
> dependent on some other system/environment.
>
> Yes, mail boxes works quite nice, but there are some issues with
> having multiple readers on a mailbox. And you can only "buffer" as
> much as our mailbox buffer has room for.

VSI still sells and supports RTR, Reliable Transaction Router.

--
Marc Van Dyck

On 4/12/2022 11:38 am, Arne Vajhøj wrote:
> On 12/3/2022 10:27 PM, Arne Vajhøj wrote:
>> On 12/3/2022 10:16 PM, Richard Maher wrote:
>>> On 3/12/2022 10:16 pm, Arne Vajhøj wrote:
>>>> Message queues has become a part of most new solutions today.
>>>>
>>>> There are 3 big players in the message queue server market: -
>>>> RabbitMQ - ActiveMQ/ArtemisMQ - Kafka
>>>>
>>>> Note 1: Kafka is not a traditional message queue server, but it
>>>> is a relevant alternative in some cases.
>>>>
>>>> Note 2: various commercial offerings from IBM, Oracle, MS etc.
>>>> still exist but the open source ones dominate the market.
>>>>
>>>> But in many ways the choice of server is not so important as
>>>> standard protocols has been created to talk to to those
>>>> servers: AMQP, STOMP and MQTT.
>>>
>>> Personally, I see message queues as a 90's solution.
>>
>> ActiveMQ is from 2004, RabbitMQ is from 2007 and Kafka is from
>> 2011.
>>
>> :-)
>>
>>> Same with ESBs.
>>
>> The big IBM/Oracle/MS/JBoss/whoever ESB's sold well up in the
>> 00's.
>>
>> But they never delivered what they promised.
>>
>> But simple message queues survived.
>
> Small and medium size solutions use ActiveMQ/ArtemisMQ or RabbitMQ
> (probably mostly depending on whether they prefer product names that
> start with J or not).
>
> Large size solutions go for Kafka. Kafka is really the only option
> for extreme workloads.
>
> A few of the big Kafka users are:
>
> LinkedIn - 100 clusters with 4000 nodes processing 7 trillion
> messages per day (2019)
>
> Pinterest - 50 clusters with 3000 nodes and a peak processing of 40
> million messages per second (2021).
>
> Arne
>

SO they use Message Queues to mirror/distribute messages/copies?
>

On 12/4/2022 9:24 PM, Richard Maher wrote:
> On 4/12/2022 11:38 am, Arne Vajhøj wrote:
>> Small and medium size solutions use ActiveMQ/ArtemisMQ or RabbitMQ
>> (probably mostly depending on whether they prefer product names that
>> start with J or not).
>>
>> Large size solutions go for Kafka. Kafka is really the only option
>> for extreme workloads.
>>
>> A few of the big Kafka users are:
>>
>> LinkedIn - 100 clusters with 4000 nodes processing 7 trillion messages
>> per day (2019)
>>
>> Pinterest - 50 clusters with 3000 nodes and a peak processing of 40
>> million messages per second (2021).
>
> SO they use Message Queues to mirror/distribute messages/copies?

ActiveMQ/ArtemisMQ or RabbitMQ are typical just for async transactional
processing.

The big Kafka users use it for distributing data in general and
the highest volume is probably from the transactional system to
the analytical system.

If you go to one of those web sites then they log everything you
do and analyze your behavior to show you the right ads. But that
stuff does not move by magic - it flows through Kafka.

So when you move every page shown, every graphics shown, every click
made by hundreds of millions of users then it becomes humongous
amount of data.

Arne

On 5/12/2022 10:39 am, Arne Vajhøj wrote:
> On 12/4/2022 9:24 PM, Richard Maher wrote:
>> On 4/12/2022 11:38 am, Arne Vajhøj wrote:
>>> Small and medium size solutions use ActiveMQ/ArtemisMQ or RabbitMQ
>>> (probably mostly depending on whether they prefer product names that
>>> start with J or not).
>>>
>>> Large size solutions go for Kafka. Kafka is really the only option
>>> for extreme workloads.
>>>
>>> A few of the big Kafka users are:
>>>
>>> LinkedIn - 100 clusters with 4000 nodes processing 7 trillion
>>> messages per day (2019)
>>>
>>> Pinterest - 50 clusters with 3000 nodes and a peak processing of 40
>>> million messages per second (2021).
>>
>> SO they use Message Queues to mirror/distribute messages/copies?
>
> ActiveMQ/ArtemisMQ or RabbitMQ are typical just for async transactional
> processing.
>
> The big Kafka users use it for distributing data in general and
> the highest volume is probably from the transactional system to
> the analytical system.
>
> If you go to one of those web sites then they log everything you
> do and analyze your behavior to show you the right ads. But that
> stuff does not move by magic - it flows through Kafka.
>
> So when you move every page shown, every graphics shown, every click
> made by hundreds of millions of users then it becomes humongous
> amount of data.
>
> Arne
>
>
>
>

Cool. It was the first/original requiremwnt of async txn processing that
I think has come and gone.