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

Dave,

I believe you will find that the RPG procedure pointer is implemented as 
an open pointer -- which can hold a system pointer.

Bruce Vining




Dave Schnee <DSchnee@xxxxxxxxxxxxxxxxxxx> 
Sent by: midrange-l-bounces@xxxxxxxxxxxx
06/14/2006 08:10 AM
Please respond to
Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>


To
midrange-l@xxxxxxxxxxxx
cc

Subject
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