Welcome to blog.qpgmr.de Discussions!

[qpgmr-de]

👋 Welcome!

I'm using Discussions as a place to connect with the readers of my blog. I hope that you:

• Ask questions you’re wondering about.
• Share ideas.
• Engage with other community members.
• Welcome others and are open-minded. Remember that this is a community we
  build together 💪.

If you like, comment below with an introduction of yourself.

[bmcpherson-srlife]

Hello! I've enjoyed reading your blog, starting originally with the one on threads. I did want to ask if you could do a topic on the use of data queues, as I would explore how they could be applied in modern processes. Thank you so much!

[qpgmr-de]

Hi,
well - from my point of view, data queues don't have a real role / advantage in modern processes. Maybe that's why I never wrote much about them.

IMHO data queues shouldn't be used for new designs - use a "communication table" where one process can insert records - and another process (or multiple processes) can "receive" (read und update) them. Combined with journaling and commitment control, there is no chance for a loss of data.

Let's look at data queues with a cold eye:

1. A data queues takes data in an unformatted / flat form - both the sender and the receiver have to use identical data structures to be sure, that the data is interpreted correctly. A table has a record format - all data is in individual cells - you can design sender and receiver in an independent form.

2. A data queue has no protection for the data - if the receiver takes an entry from the data queue, and then crashes - data is lost. A journaled table with COMMIT/ROLLBACK does guarantee, that the transaction is finished, and data isn't lost during a crash - if no COMMIT has been made, the transaction is rolled back after the crash.

3. The is no history - if an data queue entry is received, it's removed - you can't see when it was removed or by who - with a table you can take a simple BOOLEAN column "processed" - the sender inserts the data with processed=false - the receiver only reads data with processed=false and sets processed=true and maybe some additional columns (like processing timestamp, processing job, etc).

4. When a system crash occurs, a data queue can get corrupted to a degree, where you only can delete and re-create the data queue. Until this is done, alls processes with the data queue fail.

So IMHO - don't use data queues - use some form of transient tables, that hold the entries - make some clever constraints and indexes and you are fine. Maybe I should write some comparison of both solutions - let's see.

But for your question - there are several IBM services, that make data queue handling easier than it should be:

• https://www.ibm.com/docs/en/i/7.6.0?topic=services-data-queue-info-view
• https://www.ibm.com/docs/en/i/7.6.0?topic=as-send-data-queue-send-data-queue-binary-send-data-queue-utf8-procedures
• https://www.ibm.com/docs/en/i/7.6.0?topic=services-receive-data-queue-table-function
• https://www.ibm.com/docs/en/i/7.6.0?topic=services-data-queue-entries-table-function

If you still want to use data queues after all my "ranting" against them - this is the easiest way to send and receive data - get infos about the data queue and even peek into the entries without receiving them.

HTH
Daniel

[bmcpherson-srlife]

I apologize for the late reply, but I appreciate your input on the matter of data queues. Should you choose to explore the topic further, I would enjoy reading it if only to expand my knowledge on the topic. We make use of some software which utilizes data queues, which is what initially spurred my curiosity on the topic.

Thanks again and I look forward to your future posts!

[qpgmr-de]

Well it sounds like the topic is worth at least a small post, how to utilize data queues with SQL - so if I have some spare time this week, I will write something. Just stay tuned.