View Full Version : Dataqueue Behavior
12-31-1969, 06:00 PM
I don't know where that exact article is from. But, I did find, a article from Midrange computing on their resource CD. It's dated August 1990. I don't think much has change since then.
01-01-1995, 02:00 AM
Hello, all. I was recently searching the 'net for information regarding AS/400 dataqueues, and ran across some information I swear was from an IBM manual of some sort. The clip I saved reads as follows: "Data Queues only grow - they never get smaller. As entries are removed the system does not reclaim the storage used, so the space allocated fills up. When the space allocated to the data queue is used up, the system automatically extends the data queue. This characteristic makes it imperative that data queues are deleted and recreated periodically. As entries are added, retrieval become progressively slower, therefore regular housekeeping is important to keep data queues performing to their optimum." Does anyone happen to know what document this is in or point me to some more information? I must not have bookmarked the page...I know it's a long-shot, but if anyone has anything more on this I'd appreciate any input. Thanks! Ron Eisele
11-27-2000, 10:50 AM
It seems to me this excerpt is from the CL Programming Guide manual. By the way, I have written and tested a few tools to maintain dataqueues, like List Dataqueue Information Retrieve Dataqueue Description Move Dataqueue Messages Copy Dataqueue Entries Create Duplicate Dataqueue Reorganize Dataqueue If interested, I could put them in a ZIP-file and mail them to you. I tested them on V3R2M0. Regards, Carel Teijgeler
11-27-2000, 11:05 AM
Ron, <font color=blue>"if anyone has anything more on this I'd appreciate any input."</font> I thought the info was in the CL Programming manual, but the closest thing to the quote I could find was this reference: "When an entry is received from a data queue, the entry is removed from the data queue but the auxiliary storage is not freed. The same auxiliary storage is used again when a new entry is sent to the data queue. The queue grows larger as entries are sent to the queue and not received. Performance is better if the size of the queue is kept to less than 100 entries. If a data queue has grown too large, delete the data queue using the Delete Data Queue (DLTDTAQ) command, then re-create the queue using the Create Data Queue (CRTDTAQ) command." However, it should also be noted that V4R5 offers a new option to automatically reclaim dtaq space whenever the dtaq has the last entry removed. See the AUTORCL(*YES) option which works in tandem with the SIZE() option in V4R5. When reclaimed, a dtaq reverts to the initial allocation specified in SIZE(). Using SIZE() and AUTORCL(*YES) allows a process to grow if necessary during peak demands, and return to "normal" size automatically when the process catches back up and removes all entries. Doug
11-27-2000, 12:35 PM
Thanks for all the leads! I'll go check out the CL Programming Manual as noted in a couple responses, and see if I can dig up that previous MRC article that was mentioned. To Carel Teijgeler: I would be interested in seeing your 'Create Duplicate Dataqueue' program if you wouldn't mind. A side project I'm involved in seeks to write a C or Java program to be run on a client machine to simply list the dataqueue entries, but I keep running into dead ends. Using the Java As/400 Toolbox, I can perform a read(), but it's destructive. I can peek() at an entry, but can find no way to cycle through. What I needed was a way to create a duplicate dataqueue and simply do the destructive read against that (which I've had no luck with yet). If you want to drop me anything by email, the address is email@example.com Once again, thanks for all the responses! Ron
11-27-2000, 12:48 PM
Hi Ron, I've got a "Work With Data Queues" command that lets you display data queue entries interactively. It's non-destructive and it's written in C. If you want I'll send you the code and you can pick it apart for things you might need.
11-28-2000, 02:04 PM
Hi Herb, Thanks for the offer, but...gee, I feel like I'm getting off too easy here! I guess I have a question: how was it written? The path I was seeing was to a) do a dumpobj command over the queue and then b) parse the data out of the spool file that's generated. Is that how yours was written or was it with some of the OS api calls? Again, thanks! Ron
11-29-2000, 05:58 AM
API calls ... definitely!
11-29-2000, 07:17 AM
Well, actually, the more I think about it ... I wrote this on V3R2 and I don't believe the data queue APIs were available at the time (at least not documented and I wasn't aware of them!). So, while this command does use APIs to do things like create user spaces and retrieve lists of objects, the actual data queue stuff is done with MI function calls. This underlines one of the problems I have ... When I restored the objects onto a V4R4 box I encountered problems when running at security level 40. The command was bombing because I kinda perform illegal operations on certain types of objects. It works and everything, it's just that at level 40 there's enforcement to ensure that only proper operations are performed. For those curious types out there ... I THINK it's because I'm using USER queue functions to access DATA queues. It works but level 40 frowns upon it. So, the code won't work on level 40 but it would be relatively simple to replace the few BAD parts with API calls. I'd do it but I don't have access to a C compiler anymore. On the other hand, I do have an RPG version (it doesn't have as much functionality as my command) that does the non-destructive read using APIs. Someone else from this forum wrote it and sent it to me. My apologies ... I forget who. Herb
Powered by vBulletin® Version 4.1.5 Copyright © 2013 vBulletin Solutions, Inc. All rights reserved.