Re: Efficiency question on file extents...

Update...

Yesterday we ran our first conversion process since making the file size and allocation changes that were discussed in this thread.

I changed the large files to have SIZE(XXXXXXX 10000 100) ALLOCATE(*YES), where XXXXXXX is the number of records generated during the previous conversion + 10 %, then cleared the files to activate the file allocation.

There is basically one file which drives the entire process, so I have based my performance measures on the number of records processed per minute from this file.

So far, we are seeing a significant improvement in processing times.

Before making the file allocation changes, the job which builds the driver file was averaging 8500 records processed per minute.
After making the file allocation changes the same job was processing over 13,000 records per minute, a 52 % improvement.

Another very complex job ran for over 10.5 hours to process 1.1 million records during the previous conversion (1746 recs/minute).
This time it ran for 5.5 hours to process 780,000 records (2363 recs/minute), a 35 % improvement.

- sjl


I Wrote:
I have a very long-running conversion job stream which we are about to kick
off, and I'm wondering if it will save time if I change the PF's to have an
initial size that is at least as large as the number of records that I know
will be written to each file.

For example, I have an address master file named ADDRESSES which ended up
with almost 500,000 records during the last conversion.

Will it save much time if I do CHGPF(ADDRESSES) SIZE(500000 10000 100)
ALLOCATE(*YES) so that it will have an initial allocation of 500,000 records
once it is cleared, instead of letting it default to SIZE(100000 10000 100)
and the system having to do extents on it once it hit the maximum size of
100,000 records?

Regards,
sjl