DDQNM S 10 INZ(‘dqueue name ‘)
D DQLIB S 10 INZ(‘lib name’)
D DQSZ S 5 0 INZ(2000)
D DQDTA S 1400
D#Go S 1 INZ(‘ ‘)
A data queue provides a communication pipe between two or more programs. Programs may place messages (entries) on the queue and other programs (or the same program) receives the messages from the queue. When a data queue entry is received by a program, the entry is automatically removed from the queue. (If two programs are receiving entries, only one of them will get the entry.)
The sending program can be in one job, and the receiving program can be in a different job. This is the primary reason that data queues may be considered to be communications objects.
A program requests an entry from the queue and specifies a time limit to wait. The program will either receive an entry and begin to process it or it will sit doing nothing until the time runs out. The first thing a program normally does after requesting an entry is to check the parameter that tells how long the entry is that was returned. If the length is zero, the program knows that the timeout was reached and no entry was returned.
Because the program can wait until an entry arrives, a data queue can be used as a kind of “wake-up call”. The program essentially sleeps for however much time goes by until some other program sends a message.
Data queues can be keyed. Programs can request entries that have specific key values. One program might wait for entries with keys like ‘ABCDE’ while a different program waits for keys like ’12345′. Whichever entry shows up, the program that is waiting for that key will get the entry. The other program continues to wait.
More than one program can wait on queue entries. This allows you to have a bunch of programs in different jobs processing entries. If entries come in too fast, you can simply start an additional receiver job. One of the data queue APIs tells you how many entries are on a queue. This can let you know if entries are backing up.
You might have multiple receiver jobs for cases where processing entries takes much longer than generating entries. If it takes three times longer to process an entry than to generate one and entries are constantly arriving, then that might indicate you should have three receiver jobs running. You might have requests being entered from a web interface. One program receives the requests and places them on a queue, then goes back to wait for another request — it does no processing of the requests. Other jobs pull from the queue and do the request processing.
In any case, the “advantages” are the same as in any object you might use in programming. The advantages are in whatever you can imagine to do with them.