Re: Data Queue - non-destructive reads

As Carsten suggested, if the *DTAQ was created using SENDERID(*YES) then the Sender Information is included in the retrieved message text entries ¿preceding? the message data. Although poorly documented in the QMHRDQM API v5r4 documentation [link now included in quoted message], that data is the 36 bytes of the "last four fields, together, combine to make up the sender ID" as defined by the v5r4 documentation for the QRCVDTAQ API in the "Format of Sender Information":
http://publib.boulder.ibm.com/infocenter/iseries/v5r4/topic/apis/qrcvdtaq.htm

The receiver variable size adjustments [alluded to in my message], to limit the number of messages, would have to account for that extra sender information. To know if the "Include sender ID" information was specified on the *DTAQ, there is:
_i Retrieve Data Queue Description (QMHQRDQD) API i_
http://publib.boulder.ibm.com/infocenter/iseries/v5r4/topic/apis/qmhqrdqd.htm

Irrespective of the Sender Identification specification for CRTDTAQ, if the Data Queue object is journaled, then the messages with the sender information could generally be obtained from the journal instead of from the queue object itself. Depending on the requirements of the application that wants to get the messages, the possibility exists to use a retrieve\receive journal entry API instead of either API QRCVDTAQ or QMHRDQM to similarly /read/ [the Q-QS journal entries for] the messages that were deposited on the queue. Using the data in the journal [receivers] also enables visibility for any entries that may have already been processed by a destructive Receive Data Queue Entry request, rather than only those messages physically remaining on the queue.

Regards, Chuck

On 01-Mar-2012 08:46 , Gqcy wrote:

the QMHRDQM api will not pass me the Sender info, which are the
elements of information I need.

On 3/1/2012 10:40 AM, CRPence wrote:

On 01-Mar-2012 07:08 , Gqcy wrote:

I am attempting to read a data queue (non-keyed, FIFO) to
determine the Sender info, and am setting the remove entry to
*NO.

however I keep reading the same (first) record. Is there a trick
to progress through the data queue???

I see that the DSPDTAQ utility uses DMPOBJ to get at the data
queue data, but I would like to use QRCVDTAQ if I can...

If not for DDM DTAQ objects, then use the QMHRDQM API to get all of
the messages. Limit the receiver size according to the number of
messages that should be read; use the 'R'everse invocation if\when
alternate of the LIFO or the FIFO is desirable.

i_ Retrieve Data Queue Message (QMHRDQM) API i_

http://publib.boulder.ibm.com/infocenter/iseries/v5r4/topic/apis/qmhrdqm.htm

<<SNIP>>