Sorry, should have added, I create the data queue at the top of the loop. Here how it looks to me - been a while. 1. Queue can be created as *LIFO then when you Receive from it you would get the last entry 2. But I think you are created it with SEQ *KEYED - send to it including the KLen and KeyVal - receive from it includes the Klen, desired KeyVal, and keyRule as'EQ' so if you requested key EQ 'R00001' you would only get that record but if you requested key GE 'R00001' you will get one of the entries. Don't know why one time you get FIFO and the next time LIFO. Stupid me - I figured out my problem At the end of my first run, the last QRCVDTAQ gave me a key value = 'R00024' I didn't reset this to blanks when I started my next loop - and since the DQ is keyed, it positioned to the entry = 'R0024'. As soon as I reset my key field at the top of each loop, I got the results I needed. Thanks for your help!! For anyone who finds this discussion a mystery, data queues are a really slick AS/400 tool for passing data to another job. The receiver isn't running in the same job, doesn't have to be running at the time the request is made or can be running and waiting for the next request. Example: The order entry program puts order numbers to be shipped onto the shipQ. The shipping program services the shipQ picking up orders numbers in the sequence they were put on the Queue or in a keyed sequence .. urgent might be keyed A and others (N)ormal. The shipping program may be waiting for the next order or might be running 20 or 30 orders behind. ================================================== Also, Any number of jobs can be placing entries on the queue, and any number of other jobs can be pulling entries off the same queue. This allows you to adjust the number of sending or receiving jobs when you need to tune the processing for an even workflow. If the queue starts to fill up (there is a definite limit), then you start an additional receiver job. Also, data queues may be keyed or non-keyed. Entries from a keyed data queue may be pulled by key. That allows you to direct a particular entry to a specific receiving job or to do whatever you can think of for a key to control. Entries from a non-keyed data queue can be pulled in FIFO or LIFO sequence. One program can send and receive through the same data queue. A LIFO data queue then acts like a push/pop stack. An entry is removed from the queue when it is received. Data queues <b>are not</b> for permanent storage nor for write-once/read-many. Locks do not work on data queues. That is, if one job sets an *EXCL lock, another job won't be stopped from doing whatever it wants to do with or to the data queue, including deleting it. Locks are established; they're just not enforced by the system. You must test the lock yourself if you need lock control. The lack of lock enforcement by the system is one of the reasons that data queues can provide fast and efficient inter-process communication. Tom

Sorry, should have added, I create the data queue at the top of the loop. Here how it looks to me - been a while. 1. Queue can be created as *LIFO then when you Receive from it you would get the last entry 2. But I think you are created it with SEQ *KEYED - send to it including the KLen and KeyVal - receive from it includes the Klen, desired KeyVal, and keyRule as'EQ' so if you requested key EQ 'R00001' you would only get that record but if you requested key GE 'R00001' you will get one of the entries. Don't know why one time you get FIFO and the next time LIFO. Stupid me - I figured out my problem At the end of my first run, the last QRCVDTAQ gave me a key value = 'R00024' I didn't reset this to blanks when I started my next loop - and since the DQ is keyed, it positioned to the entry = 'R0024'. As soon as I reset my key field at the top of each loop, I got the results I needed. Thanks for your help!! For anyone who finds this discussion a mystery, data queues are a really slick AS/400 tool for passing data to another job. The receiver isn't running in the same job, doesn't have to be running at the time the request is made or can be running and waiting for the next request. Example: The order entry program puts order numbers to be shipped onto the shipQ. The shipping program services the shipQ picking up orders numbers in the sequence they were put on the Queue or in a keyed sequence .. urgent might be keyed A and others (N)ormal. The shipping program may be waiting for the next order or might be running 20 or 30 orders behind. ================================================== Also, Any number of jobs can be placing entries on the queue, and any number of other jobs can be pulling entries off the same queue. This allows you to adjust the number of sending or receiving jobs when you need to tune the processing for an even workflow. If the queue starts to fill up (there is a definite limit), then you start an additional receiver job. Also, data queues may be keyed or non-keyed. Entries from a keyed data queue may be pulled by key. That allows you to direct a particular entry to a specific receiving job or to do whatever you can think of for a key to control. Entries from a non-keyed data queue can be pulled in FIFO or LIFO sequence. One program can send and receive through the same data queue. A LIFO data queue then acts like a push/pop stack. An entry is removed from the queue when it is received. Data queues <b>are not</b> for permanent storage nor for write-once/read-many. Locks do not work on data queues. That is, if one job sets an *EXCL lock, another job won't be stopped from doing whatever it wants to do with or to the data queue, including deleting it. Locks are established; they're just not enforced by the system. You must test the lock yourself if you need lock control. The lack of lock enforcement by the system is one of the reasons that data queues can provide fast and efficient inter-process communication. Tom