Data Queues provide a speedy, versatile, and functional program-to program communication method and also provide a perfect coupling and transaction layer in modern application design models, aiming at separating the data processing and business logic from the presentation layer, and thus achieving independence between the back-end and the front-end of the application.
Over the years I’ve seen data queues being used for a variety of mission critical and performance sensitive applications. Examples of such applications include OTC (On Truck Computer) distribution and billing systems, credit card transaction and monitoring systems, travel reservation systems as well as a number of full scale web business applications.
Although I during this time have run into minor issues and challenges using data queues, I’m generally very impressed with the speed, robustness and functionality offered by data queues. Adding to this that the asynchronous program-to-program communication method offered by data queues also very well support contemporary application development and design models is yet another quality distinguishing data queues.
When using data queues in application development you’ll sometimes encounter situations calling for the assistance of a data queue CL command in order to quickly progress the task at hand. The i5/OS operating system however only include the very basic CL commands and I’ve therefore developed my own, additional set of data queue CL commands which I will also be presenting today along with links to other on-line data queue resources.
I’ll briefly talk about the other queue object on the i5/OS, known as a User queue and having a symbolic object name of *USRQ a little later – and also point you to articles and programming examples covering user queues.
Standard data queues are data queues residing on the local system as opposed to DDM (Distributed Data Management) data queues pointing to data queues residing on other (remote) systems. The *DDM attribute refers to the original implementation of remote data queues which was established by the DDM architecture and a SNA/APPC (Systems Network Architecture/Advanced Program-to-Program Communication) infrastructure including configuration attributes such as Remote location, APPC device description, Local location, Mode and Remote network identifier and which involved all the challenges of making such a setup work. Luckily, today another, simpler approach of defining the remote location by means of the Relational Data Base (RDB) infrastructure is available – more details to follow.
Note that data queue entries are sometimes referred to as messages, but for the context of this presentation I’ll simply be using the term entry. As for the significant data queue Sequence attribute the following brief explanation is intended to serve as a general guideline when defining data queues:
- A First-in-first-out (FIFO) sequenced data queue ensure that entries are received in the same order as they were added. This is for example useful for an application inbound transaction data queue, causing all transactions to be served in the order they arrive.
- A Last-in-first-out (LIFO) sequenced data queue ensure that entries are received in the opposite order as they were added. This could be useful to establish a stack type of object, for example preserving the call level order of entries in a system data queue. As call levels are added and current application or runtime values are overwritten, these are saved in the LIFO data queue and retrieved and applied on return from higher call levels.
- A keyed data queue supports a variety of design objectives such as ensuring that specific data queue entry processing programs receive only the entries that they are supposed to handle – or that a client submitting a data queue entry to a server will receive only the response for which it is specifically waiting.
Articles on Apis 