Hi, Larry
Create the *USRSPC with QUSCRTUS and change the *USRSPC attribute to automatically extend with QUSCUSAT. Then whenever you want to work with the *USRSPC use QUSPTRUS to retrieve a pointer to the first byte of the *USRSPC. After that you can work with the *USRSPC directly with the pointer. If you write (or for that matter even read) a location of the *USRSPC that doesn't exist (yet) the system will autoextend the *USRSPC to the location (or at least to that location, you may well get a bit more) referenced.
Be aware that using QUSCHGUS provides a level of locking that you will now be responsible for if you have multiple jobs concurrently reading and writing from the *USRSPC using direct pointer manipulation.
Also be aware that the *USRSPC must be created in the user domain if you want direct pointer manipulation (as you will be bypassing the APIs which also can provide a level of auditability).
You obviously haven't been reading some of my API related articles lol. I use pointer access to *USRSPCs quite frequently when working with list APIs. And all of this (plus more) is discussed in my APIs at Work book (a slight vendor plug).
Bruce
Larry Ducie <larry_ducie@xxxxxxxxxxx> wrote:
Hi Simon,
There is no real difference between *USRSPC storage and allocated
storage (other than the permanence of the *USRSPC).
If you're using the QUSCHGUS and QUSRTVUS APIs then I can believe
they'll be slower than direct pointer access to storage however you
can get a pointer to the user space and then it's just as fast as
your allocated storage method.
OK, I need clarification.
Are we saying I can create a User Space and retrieve the pointer to the beginning of the storage within it, and I can then write directly to that pointer and the storage will expand as I need it to? If that is the case then User Spaces are better than I thought.
It was my understanding though, that the storage within a User Space would only expand if you used the QUSCHGUS API to write to it. If that is the case then my statement still stands. What possible benefit would a User Space have over a standard data pointer other than the permanence of the data? If all I get is a regular pointer then I there is no point using a User Space. If I wanted the data within a permanent store I'd use a stream file.
f you see significantly slower access times using a pointer to a
user space than using a pointer to allocated storage then I'd like to
see your test code.
Sadly, its no longer my code - it was performed 3 years ago, for another employer, in another hemisphere. But the results were valid. Of course, the access to the User space data was via the APIs, not direct pointer access, and the time for the creation of the User Space was also included in some of the tests. But an overhead is an overhead however you slice it.
Maybe user spaces have a use as a temporary data storage used by multiple jobs if they are faster than using stream files.
I am wiling to be convinced.
Cheers
Larry Ducie
_________________________________________________________________
Meet singles near you. Try ninemsn dating now!
http://a.ninemsn.com.au/b.aspx?URL=http%3A%2F%2Fdating%2Eninemsn%2Ecom%2Eau%2Fchannel%2Findex%2Easpx%3Ftrackingid%3D1046247&_t=773166080&_r=WL_TAGLINE&_m=EXT
midrange.com
