RE: Different processing times...why?

[Vernon Hamberg <vhamberg@xxxxxxxxx>]

This is exactly right. With sufficient memory, all that data (including
indexes) could reside in memory. This is the principle behind using
SETOBJACC - once something is in memory, it is available to ALL processes.
If you devote a pool to memory-persistent objects, and have no jobs running
in this pool, you can put your frequently-used data there and guarantee
more consistent and usually shorter processing. For batch-like processing,
running SETOBJACC first (which is supposed to be the most efficient way to
get data into memory) can allow your job to complete faster. Doing this in
a separate submitted job could even lend a certain degree of parallelism,
esp. if the processing job runs the data sequentially.

At 06:38 AM 7/13/02 -0400, you wrote:
>Ray,
>
>Here's a possible explanation.  Whether it's accurate or not would
>depend on how busy your system is and how much main storage you have in
>the pool in which your job is running.
>
>When any program reads data from a file, it must bring the data into
>main storage.  Generally speaking, this data will stay in memory until
>the system needs to use that memory for something else.  On the first
>pass through the program, probably all data needs to be brought into
>main storage by going to the disk and doing a lot of reads.  These disk
>reads will take a fair amount of time.
>
>Depending on available main storage, a large amount of this data could
>still be in memory when you run it the second time, so most "disk
>accesses" will actually occur in memory, leading to considerably shorter
>processing times.
>
>Regards,
>Andy
>
> > On Behalf Of Ray Nainy
> > Subject: Different processing times...why?
> >
> > We have an RPG program that reads approximately 4500 records from
> > file A and reads matching records in file B using account number.
> > File B has a total of 2 million records.
> > It takes about 60 to 70 seconds to complete the processing when the
> > program
> > is called for the first time. But it takes only 3 to 4 seconds to
>complete
> > the processing, when the program is called again 2nd or 3rd or 4th or
> > 5th...time. Processing time is 60 to 70 seconds only for the first
>call.
> > This happens again if the session is idle for 20 minutes or more. We
> > couldn't find out why is this processing time more only for the first
>call
> > to the RPG program. We verified and found that this problem exist
> > anytime, irrespective of the peak/non-peak hours of the day.
> >
> > Any help is greatly appreciated.
> >
> > Ray