Data queues are an efficient way for two or more programs to communicate with one another. The programs might reside on the same AS/400, or one might be on an AS/400 and another on a PC.

You might compare data queues to a mailbox. Post office personnel put things into the mailbox, and the people with keys to the box take them out. A mailbox holds letters, but a data queue holds data records called messages. Don't confuse them with the messages sent by commands like SNDMSG. They're not the same thing.

Data queues have been around since the S/38 days, but keyed data queues are a fairly recent invention. Before keyed data queues, you could retrieve entries from data queues in first-in-first-out (FIFO) or last-in-first-out (LIFO) order only.

Keyed data queues aren't any better or worse than FIFO and LIFO data queues; they're just different. They offer other capabilities, namely the ability to select and sequence the messages on a data queue. Before I talk about how to use keyed data queues, let's look at the commands and APIs you'll need to work with them.

The Create Data Queue (CRTDTAQ) command creates data queues, keyed as well as nonkeyed. To create a keyed data queue, specify SEQ(*KEYED) and provide the length of the key in the key length (KEYLEN) parameter. The following command creates a data queue named MYDTAQ in library MYLIB. The messages will be 1024 bytes long, and the key will be 8 bytes long.

 CRTDTAQ DTAQ(MYLIB/MYDTAQ) + MAXLEN(1024) SEQ(*KEYED) + KEYLEN(8) 

To place some data on the data queue, call the Send Data Queue (QSNDDTAQ) API. QSNDDTAQ usually requires only four parameters, but if you're sending data to a keyed data queue, you'll need two more-the key data and the length of the key data. You can see the parameter list for QSNDDTAQ in 1.

To place some data on the data queue, call the Send Data Queue (QSNDDTAQ) API. QSNDDTAQ usually requires only four parameters, but if you're sending data to a keyed data queue, you'll need two more-the key data and the length of the key data. You can see the parameter list for QSNDDTAQ in Figure 1.

Use the Receive Data Queue (QRCVDTAQ) API to receive an entry from the data queue. Keyed data queues require three parameters that are not permitted for *LIFO and *FIFO data queues. You'll have to specify a key search criteria, the length of the key value, and the key value itself. See 2 for the complete parameter list for QRCVDTAQ.

Use the Receive Data Queue (QRCVDTAQ) API to receive an entry from the data queue. Keyed data queues require three parameters that are not permitted for *LIFO and *FIFO data queues. You'll have to specify a key search criteria, the length of the key value, and the key value itself. See Figure 2 for the complete parameter list for QRCVDTAQ.

The key search criteria can be one of the six usual relational operators-EQ, NE, GT, LT, GE, or LE. QRCV-DTAQ uses the key value you provide to search for an appropriate entry on the data queue.

If you'd like to look at the messages on a data queue without removing them, you can use the Retrieve Data Queue Message (QMHRDQM) API. See the OS/400 System API Reference V3R1 manual for more details.

PCs running Client Access/400 can create, delete, read from, write to, and otherwise massage data queues on the AS/400, through either batch file commands or APIs. It's easier to use commands, but they're limited in what they can do. For more power, use the Client Access APIs. The Client Access/400 API reference manuals listed at the end of this article describe them and show how to call them from programs written in languages like C and Pascal.

One thing keyed data queues do is let you retrieve entries in a sorted order, regardless of how they arrived on the queue. This is a good way to prioritize the messages in a data queue.

One example of this is the use of data queues to replace data entry. It's common for an AS/400 shop to modify a data entry program to read from a data queue instead of a terminal. This program usually runs in batch, receiving the messages as they hit the data queue and processing them as soon as it can.

If messages are usually processed as soon as they arrive on the data queue, any organization of data queue-FIFO, LIFO, or KEYED-is acceptable. If messages arrive in groups, so that there are often several messages waiting on the queue, you can prioritize them with a keyed data queue.

1 contains code that places inventory transactions on a keyed data queue. The ACTION field has the value 0 if the transaction increases inventory, and 1 if the transaction decreases inventory. Placing ACTION at the beginning of the key forces the system to process transactions that increase inventory, such as receipts, before transactions that decrease inventory, like issues or scrap, when two or more messages are waiting in the queue.

Figure 1 contains code that places inventory transactions on a keyed data queue. The ACTION field has the value 0 if the transaction increases inventory, and 1 if the transaction decreases inventory. Placing ACTION at the beginning of the key forces the system to process transactions that increase inventory, such as receipts, before transactions that decrease inventory, like issues or scrap, when two or more messages are waiting in the queue.

The batch transaction job would include code like that in 2. The program waits for a transaction to arrive on the data queue, processes it, and waits for another one.

The batch transaction job would include code like that in Figure 2. The program waits for a transaction to arrive on the data queue, processes it, and waits for another one.

For more ideas, you should also read "Line Up for Data Queues" (MC, May 1992). There, you'll find a program that uses a keyed data queue to sort a subfile.

Another reason to consider key data queues is that FIFO and LIFO data queues have a take-it-or-leave-it attitude. When you ask for an entry from one of these types of queues, you have to take the next entry in line. Keyed data queues allow you to select the entries you want and ignore the others.

For example, suppose you call QRCVDTAQ with a key value of MA and a search operator of GT. QRCV-DTAQ looks for a data queue entry with a key value greater than MA. If two or more messages in the queue have key values greater than MA, QRCVDTAQ retrieves the one that arrived on the queue first.

One good use for this is sending information to different processes through a common data queue. These processes could be terminals that display messages and announcements in different warehouses (the way CRT screens in airports display flight information). The terminal in each warehouse would receive the messages for that warehouse. The processes could be running on PCs, and each PC could pick just the messages intended for it. The processes could be separately running never-ending batch jobs that send the information to different printers.

For more examples, see the articles "Easy Cooperative Processing Programming with Data Queues" (MC, October 1993) and "Event-driven Programming with Data Queues" (MC, December 1993).

The speaker at a meeting I attended told us that we all had great potential. Once he had us feeling good about ourselves, he explained that "potential means you haven't done it yet." If keyed data queues are still a potential in your shop, they're worth your consideration. The possibilities for keyed data queues are enormous, especially when keyed data queues are accessed by PCs.

Ted Holt is an associate technical editor for Midrange Computing. He can be reached by E-mail at This email address is being protected from spambots. You need JavaScript enabled to view it..

An Introduction to Keyed Data Queues

Figure 1: Sending Data Queue Messages with QSNDDTAQ

 IDQDTA DS 1024 ... C QTY IFNE *ZERO C ACTION CAT ITEM:0 KEY C MOVELQTY DQDTA C CALL 'QSNDDTAQ' C PARM 'MYDTAQ' DQNAME 10 Data queue name C PARM 'MYLIB' DQLIB 10 Data queue library C PARM 1024 DQLEN 50 Data queue length C PARM DQDTA Queued data C PARM 8 KEYLEN 30 Key length C PARM KEY 8 Key value C ENDIF 
 
An Introduction to Keyed Data Queues
 
Figure 2: Receiving Data Queue Messages with QRCVDTAQ
 
 ... IDQDTA DS 1024 ... C CALL 'QRCVDTAQ' C PARM 'MYDTAQ' DQNAME 10 Data queue name C PARM 'MYLIB' DQLIB 10 Data queue library C PARM 1024 DQLEN 50 Data queue length C PARM DQDTA Queued data C PARM -1 WAIT 50 Seconds to wait C PARM 'GE' KEYSLT 2 Key selection C PARM 8 KEYLEN 30 Key length C PARM *BLANKS KEY 8 Key value C PARM 0 SNDLEN 30 Sender info length C PARM SND 8 Sender info * C* If the data queue msg contains sentinel value, shut down the job. * C '$$EOJ' SCAN DQDTA 11 C *IN11 IFEQ *ON C SETON LR C RETRN C ENDIF * ... (code to process the transaction goes here)