This is link to Craig Rutledge JCRCMDS. There is a tool to display dtaq-entries. You can download JCRCMDS and install them.
You can use the source of the retrieve-program and write the entries into a file, which you can save.
In general, there are five ways to “store” the entries in a data queue:
- Dump the data queue object to a spooled file with DMPOBJ (or DMP or DMPSYSOBJ). The spooled file takes work if you want to recover from it.
- Receive each entry with QRCVDTAQ, log it wherever you want it “stored” and then requeue the entry with QSNDDTAQ.
- Use the Retrieve Data Queue Message (QMHRDQM) API to retrieve all entries in a single operation.
- If the QMHRDQM API seems too complex, use a free-ware tool such as from Craig Rutledge above. Modify it to log the entries rather than to display them.
The QMHRDQM API has a serious limitation in that it can retrieve the first entry, the last entry or all entries. It can’t loop through entries one at a time. You either get them all at once or you get only the first or last entry. (Both options 3 & 4 have this problem.)
It might seem useful to get them all, but data queues can grow to 2GB in size in V5R4. You’ll have an interesting time figuring out creating variables that can hold that much if your data queue is of any significant size. Single data queue entries can be as large as the largest RPG variables.
IMO, the only truly reliable and useful way to “store” the entries is the fifth way — use STRJRNOBJ to journal the data queue entries. The system supports it, it has no tricky limitations and any serious problems may be the responsibility of IBM Support to fix.
I’m not sure why there’s a need to “store” data queue entries. If there are operational problems that storage attempts to solve, a data queue is almost certainly the wrong object type to be using in the first place.