Re: Are data queues reliable?

A couple of years ago I wrote a Google Web Toolkit application to receive emails and send the structured content to an iSeries via dataque. Very simple, very automatic. My memory & notes tell me that the significant lines were:

import com.ibm.as400.access.AS400;
import com.ibm.as400.access.AS400SecurityException;
import com.ibm.as400.access.DataQueue;
import com.ibm.as400.access.ErrorCompletingRequestException;
import com.ibm.as400.access.IllegalObjectTypeException;
import com.ibm.as400.access.ObjectAlreadyExistsException;
import com.ibm.as400.access.ObjectDoesNotExistException;

It all worked smoothly. Of course Google Web Toolkit withered on the vine, and I see com.ibm. as400 can not be resolved. Which could be a lot of things, which is why I get bitter.

My point is, though, that if it could be done then it can be done now, even if one avoids GWT. It really did work well.


On 12/23/2016 2:03 PM, Mark Murphy/STAR BASE Consulting Inc. wrote:

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 d
o that with a stored procedure.

Mark Murphy
Atlas Data Systems
mmurphy@xxxxxxxxxxxxxxx