Display Data Queue Description

[MCWebsite.Staff]

** This thread discusses the article: Display Data Queue Description **
** This thread discusses the Content article: Display Data Queue Description **
This is a discussion about Display Data Queue Description.

Click here for the article.

[Guest.Visitor]

** This thread discusses the article: Display Data Queue Description **
We have used data queues in the past but have since moved away from them. The main reason is that they are limited in size to 16MB. We had applications that quickly overloaded the data queues because the data queues do not shrink in size as data is retrieved. This was not a problem when we first started, but as applications ramped up in volume it became problematic. We have moved to data queue like sequential files where we wait on EOF without ever processing the EOF. As records are added to the end of the file they become available to be read and then we wait for more. The disadvantage is that we cannot use the reuse deleted record parameter and have to reorganize these files periodically to keep the disk usage down. Larry Wood LWC, Inc.

[Guest.Visitor]

** This thread discusses the article: Display Data Queue Description **
What OS version are you using? I scanned the internet and found this: The author is (I think) is an IBM'er... Just as an update, with V4R5 the maximum size is now 2GB.

For current releases (V4R4), the maximum *dtaq size as it relates to the messages is 16MB. The actual storage used to implement the *dtaq can be up to 32MB.

Bruce (Vining)

[R.Cozzi]

** This thread discusses the article: Display Data Queue Description **
Data queues are not limited to 16MB (sadly, user spaces are) I just entered the following CRTDTAQ command: CRTDTAQ DTAQ(QTEMP/ORDERS) MAXLEN(2000) + SIZE(*MAX2GB 50) AUTORCL(*YES) The SIZE parm allows you to override the default of 16MB to 2GB. You need to press F10 to see that parm on the prompter, however. The AUTORCL (auto reclaim) will reclaim the storage for the data queue (your other issue) when the data queue is empty. The storage required for the initial number of records, however (element 2 of the SIZE parm) will still be allocated.

[Guest.Visitor]

** This thread discusses the article: Display Data Queue Description **
Regarding the AUTORCL option, bear in mind that while the system is auto-reclaiming the storage it is not possible to add new records to the queue. I do not know how long a reclaim might take, but this could potentially cause the job wishing to write to the queue to fail/crash unless it properly monitors for the situation.

[Guest.Visitor]

** This thread discusses the article: Display Data Queue Description **
If you have any remote/DDM queues you will probably see corrupted data in the associated fields at the bottom of the screen. To fix this, amend the RPG/DSPF and change the fields ModeName, RmtLocName, LclLocName and RmtNetID to be 8A.

[Guest.Visitor]

** This thread discusses the article: Display Data Queue Description **
Concerning Kev (krg)'s note on the AUTORCL feature. This is true; while the storage is being reclaimed the queue is locked, and will cause your jobs to go into a LCKW status. Our solution to this was to make the initial number of entries on the CRTDTAQ a reasonable number that would ususally cover the depth of your queue. For example, if the depth of your queue usually varies from 0 to 70, make the initial number of entries something like 100. Only when the queue depth gets beyond 100 will the system attempt to reclaim the storage. As long as you pick a reasonable number, the number of times the system does a reclaim will be rare, and you still get most of the benefits of the AUTORCL feature.

[ChrisVillanueva]

** This thread discusses the article: Display Data Queue Description **
I am confused, but this may shed light on a sparatic problem we are having with out data queues. We are getting a weird error that leads us to believe that the record written to the data queue is too big, or that the data queue has filled up. "they are limited in size to 16MB. We had applications that quickly overloaded the data queues because the data queues do not shrink in size as data is retrieved." I understand that when the queue was created it was at the default of 16MB, but I don't understand about the data queue getting over loaded. We probably wouldn't have more that one or two 3032 length records in the queue and any given time. That is no where near 16MB. Is what you are saying that, after a record is retrieved the usuable space in the queue doesn't change?

---

Code

[R.Cozzi]

** This thread discusses the article: Display Data Queue Description **
The RPG IV source has been updated to correctly declare the DDM data structure that is returned (when using DDM Data Queues). If you use DDM DTAQs you might want to download the new source. As always, the source for this is available directly off of my AS/400 by going to http://www.rpgiv.com. When the home page appears, click on the "Jump to..." drop down and select "Newsletter Source Code".

[Guest.Visitor]

** This thread discusses the article: Display Data Queue Description **
The storage used for a data queue is reusable, and is based on the largest number of entries that have ever been in the queue. Think of it like a high water mark. If, at one time you had 100 entries in the queue, the storage for the queue will always reflect the space needed for 100 entries, no matter how many are currently in the queue. But, in order to hit the limit, you've got to fill up your queue. A couple of things you should know about.... A. 16Mb is the default; you can now go as high as 2Gb, which is what we use as our standard. B. You can reclaim the used storage either by recreating a queue, or by using the Auto Reclaim option when you create the queue. I believe TAATOOLs has a tool that will recreate a queue for you.