× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Thanks all,
in relation to this "poorly documented" QMHRDQM api,
does someone have a example RPGLE program using this...
I'm having trouble with the Message select data structure...



On 3/1/2012 4:46 PM, CRPence wrote:
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>>



As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.