|
Albert: You don't make it clear what you mean by "accessing". If you need to read/increment/update something in a user space or data area, you will want to prevent others from doing so at the "same time". That means allocating the object. The retrieval from or writing to a data queue does not use that kind of locking mechanism. If you use a user space and do NOT need to lock it, your speed depends upon how often you need to get a pointer to the (data part of) the space. If it's a "one guy does any updating and many guys read the current value", then the user space might be your best bet (only one guy needs to do the ALCOBJ/DLCOBJ). If many guys need to do a read-then-update, you need to allow time to locate the object for each part of ALCOBJ, Read, change, DLCOBJ - at least for a DTAARA. For a user space, you may be able to get a pointer to the space once then do many cycles of ALCOBJ, read, change, DLCOBJ which will only need to locate the object 2 times instead of 4. A data queue will need 2 rounds of "locate the object" but will also need time to get and/or put a message. The BEST speed combination if many guys need to ALCOBJ/read/change/DLCOBJ is probably the user space. I had a requirement to have many jobs doing just this and I found that the name resolution inherent in the ALCOBJ/DLCOBJ took 99% of the time if I used a user space and I could keep the pointer to the space between updates. I was able to use the MI LOCKSL and UNLOCKSL interfaces (but only in C, not RPGLE) to get a "system pointer" to the user space and save this pointer between retrieval/update cycles to save 99% of the time. That's not for the faint-of-heart but it was most effective. Dave Schnee, Barsa Consulting Group, LLC ------------- Albert York wrote ---------- date: Tue, 13 Jun 2006 08:37:47 -0800 from: "Albert York" <albertyork@xxxxxxxxx> subject: Fastest access: user space, data area, data queue I was wondering is there is any kind of significant difference in speed when accessing a user space, data area, or data queue entry. Thanks, Albert
As an Amazon Associate we earn from qualifying purchases.
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.