Re: What part of an RPG program is re-used?

[Scott Klement <rpg400-l@xxxxxxxxxxxxxxxx>]

Put the data in a user space in a shared library (as opposed to QTEMP). 
On first call, have the *SRVPGM get a pointer to the user space. Have an 
array that's based on that user space for lookups.

It's probably also possible to do it with shared memory segments. 
(Though, I don't see the value in this situation.)


On 7/5/2011 12:12 PM, Joe Pluta wrote:
> Back in the olden days, one of the things that was so efficient about
> the midrange was the way it used a shared, read-only section of memory
> for the program code.  That way, 20 people using order entry would use
> only one copy of the program.  The variables specific to a given job
> were stored in the job itself (in the Process Access Group, if I
> remember correctly).
>
> My question is how much of that still holds today?  Here's what I'm
> wondering about.  I'd like to create a service program that provides
> data from a table.  That table is static; it will not change during the
> life of the job and most likely only needs to be refreshed at IPL.
>
> I could use a database table and pin the table to memory with SETOBJACC,
> but that still means I have to go through a layer of DB management each
> time I want a value.  Unless things have changed drastically, having an
> array in my program will still be faster, especially if I have an
> ordered array with a relatively small number of elements (measured in
> the 100s at most) and then load that table at initialization time.  Even
> if the data is 1K in length, I'm talking less than 1MB of memory.
> However, what I don't want is 100 user jobs to create 100 copies of that
> table; now I'm talking megabytes and as the number of tables and users
> grows, so does the used (duplicated) memory.
>
> So, is there a way to have a static chunk of memory that is shared by
> all the jobs that call this service program?  The program code will
> certainly be shared, but what about the data?  If I create an array in
> my D-specs, as far as I know I can't make it read only.  Therefore it
> has to be in the PAG (or whatever the equivalent is), and thus is
> repeated per job.
>
> The more I look at it, the more it seems that SETOBJACC is my best bet
> and that I have to choose between speed and memory usage.  I suppose I
> can share a single user space among multiple jobs.  Or a user index,
> perhaps?  I always wonder about those sorts of objects, though, since
> every request requires a fully qualified object name.  How often do
> those get resolved?
>
> Thoughts?
>
> Joe