RE: Are data queues reliable?

Data queues are a poor man's MQ series. They perform a lot faster because they do not have all the logging and commitment control built in, and they are really single platform (though they can be used remotely by another instance of IBM i, as DDM data queues). But if you don't need multi-platform, they are way simpler to implement than MQ Series. By multi-platform, I mean multiple server platforms. Data Queues can be used in a Client Server environment for communications between IBM i and a client quite effectively. I have used that capability to improve performance of Java applications that performed complex interactions with DB2 on i by having the Java client drop a request on the queue, and a NEP processing it and sending back the response. The more interactions a client has with the DB2 on i database within a single transaction, the more improvement you will see by just passing the entire transaction off to the server once and let it determine the answer. You could also do that with a stored procedure.

Mark Murphy
Atlas Data Systems
mmurphy@xxxxxxxxxxxxxxx


-----"Slanina, John" <jslanina@xxxxxxxxxx> wrote: -----
To: "'Midrange Systems Technical Discussion'" <midrange-l@xxxxxxxxxxxx>
From: "Slanina, John" <jslanina@xxxxxxxxxx>
Date: 12/23/2016 01:39PM
Subject: RE: Are data queues reliable?


I agree 100% with you...

I mainly deal with transaction processing. I always design for an acknowledgement that process was performed.
On a side note, I do wish IBM MQ was a lot cheaper. I always want to play around with a messaging system on the IBM I.

John Slanina
Pencor Services
jslanina@xxxxxxxxxx

-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Mark Murphy/STAR BASE Consulting Inc.
Sent: Friday, December 23, 2016 1:05 PM
To: Midrange Systems Technical Discussion
Subject: RE: Are data queues reliable?

There is an API to read a data queue without removing the messages. And yes, a Data Queue is not a proper driver for a transaction processing program, but for interprocess messaging, you have to do extra work to make a database file function properly. I could say that a database file is not a proper mechanism for interprocess communications for the same type of reasons that I would say that queueing is not appropriate for transaction processing. It all really depends on your application and what you need it to do. Not every problem is a nail, and not every solution a hammer.

Mark Murphy
Atlas Data Systems
mmurphy@xxxxxxxxxxxxxxx


-----"Slanina, John" <jslanina@xxxxxxxxxx> wrote: -----
To: "'Midrange Systems Technical Discussion'" <midrange-l@xxxxxxxxxxxx>
From: "Slanina, John" <jslanina@xxxxxxxxxx>
Date: 12/23/2016 12:51PM
Subject: RE: Are data queues reliable?


my view is if I am write the data to a file to log it. They why not read the file to process the data. Other factor is how many entries will you have in the queue.
I can make a nice display around the file to see what going on. It gets messy to do that to a dataq.

John Slanina
Pencor Services
jslanina@xxxxxxxxxx


-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Mark Murphy/STAR BASE Consulting Inc.
Sent: Friday, December 23, 2016 12:12 PM
To: Midrange Systems Technical Discussion
Subject: RE: Are data queues reliable?

You don't have to lose the audit trail, you can log anything you wan in both the sending and receiving applications. If you use service programs, you can wrap the put and get calls in a sub-procedure to do the logging for you, and call that from your programs.

Mark Murphy
Atlas Data Systems
mmurphy@xxxxxxxxxxxxxxx