QRCVDTAQ size of data receiver

[Guest.Visitor]

In V4R3 IBM added parameters to the QRCVDTAQ API for: remove message, size of data receiver and error code. Since parameter 3 is for the length of data, does anyone know the significance of parameter 12, size of data receiver? Also, does anyone know of a way to process this API against an un-keyed data queue and to retrieve other than the first message in the queue? (I am trying to retrieve the messages without removing them from the queue - parm 11 is set to *NO.)

[Guest.Visitor]

The 3rd parameter is an Output where the API tells you how much data was written to parameter 4. The 12th parameter, on the other hand, is an Input where you tell the API how large parameter 4 is. Many users were burned in the past because the API assumed parameter 4 was of size parameter 3, and if it (parm 4) was smaller then appearantly unrelated application data could be over-written. For non-destructive accessing of additional messages you may want to look at Retrieve Data Queue Message (QMHRDQM) rather than QRCVDTAQ.

[Guest.Visitor]

I appreciate your response, however the QMHRDQM API will not work for me, as it requires that you specify that you want all the messages, or just the first or last message. I don't want all the messages, nor just the first or last message.

[Guest.Visitor]

I am not sure how we can retrieve dataq entries one after another. I am using TAATOOLS which has a tool to view all the entries using the command DSPDTAQ. This lists all the entries from the dataq in a subfile and does not alter the DATAQ in anyway. This means, sequencially we can retrieve all the entreies of a non keyed dataq as well. May be, you can find a way, If so, just post it. Thanks Elan

[Guest.Visitor]

Bruce is correct. Using the QMHRDQM API, to perform a non-destructive read of a data queue, sounds like just what you need. The documentation, for this API, is a little misleading. Quote from the manual: <font color=blue>The QMHRDQM API allows the retrieval of multiple messages per call. The message selection information parameter allows you to have some control over which messages are returned. The QMHRDQM API can be used to retrieve the following: The first or last message of a data queue All messages of a data queue Selected messages from a keyed data queue </font> But is also says the following: <font color=blue>Receiver variable OUTPUT; CHAR(*) The receiver variable that receives the information requested. You can specify the size of the area to be smaller than the format requested as long as you specify the length parameter correctly.As a result, the API returns only the data that the area can hold.</font> If the Select Type is ALL messages and the receiver variable is not large enough to hold all the messages in the queue, only those messages which can fit, in the space provided, will be returned. I have a set of programs for displaying the data queue descriptions and entries. What the program does is create a user space large enough to hold all the entries in a data queue and then uses this API to load all the messages into the user space. Once the space is loaded, it is possible to step through the entries using a pointer into the user space. If you would like a copy of the programs, I may be contacted at mailto:jwhensley@peerlesschain.com. Jerry Hensley Peerless Chain

[Guest.Visitor]

Thank You.

[Guest.Visitor]

From the OS/400 API reference... http://as400bks.rochester.ibm.com/pubs/html/as400/v4r5/ic2924/info/apis/obj2.htm

[Guest.Visitor]

If you take a look at how DSPDTAQ works, you will note -- * Behind the scenes, it has performed a dmpobj on the data queue, * Pulled the spool file from dmpobj into some sort of work file, * Then displayed the contents into the subfile.

[Guest.Visitor]

I was burned by this. The other thing to watch-out for is the "key order" parm (parm 6). If you specify "EQ", you're gonna get only one match, if anything. So, if your data queue consists of a series of messages whose keys are a user profile ID, you'll only get the first message with that key. The same goes for "GE", etc., too.