Re: Fastest access: user space, data area, data queue

   Dave:

    

   The problem is that RPGLE cannot handle nor pass a "system pointer" at
   all.  When you look at a pointer in RPGLE, you can see a procedure pointer
   or a space pointer and show its value (say, using STRDBG).  If you pass a
   system pointer back from MI or C to RPGLE, the "pointer" attribute (and
   value) are lost.

    

   So, yes, I did try, but I had to keep the system pointer stored in a C
   module and use an entry to that module to use the LOCK/UNLOCK mechanism to
   get this to work.

    

   Dave Schnee,

   Barsa Consulting Group, LLC

    

   - - - - -   Dave McKenzie wrote   - - - - -

    

   date: Tue, 13 Jun 2006 12:23:50 -0700
   from: Dave McKenzie <davemck@xxxxxxxxxxxxx>
   subject: Re: Fastest access: user space, data area, data queue

   Dave,

   Did you mean you didn't try LOCKSL/UNLOCKSL in RPGLE (only C), or you
   tried it in RPGLE and it didn't work?

   --Dave

   Dave Schnee wrote:
   >    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