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>>