RE: Physical File Performance

Noel,

Whether or not it would be a good idea to change the file to multiple
members strikes me as an application design issue and there is really not
enough information to give a recommendation as to whether this is a good
idea.  I don't think that an application redesign solely to allow for
file reorganizations is sufficiently justified.  Some of this would
depend on your faith in the technical competence of your vendor.

Can you deal with the space issues by changing the file to allow for the
reuse of deleted records?  If all file access is by key, this may provide
some benefit.

When you do your reorganization, do you specify a key to expedite
sequential processing, or do you just get rid of the deleted records?  If
you are reorganizing for batch performance, how long does it take for the
benefits of reorganizing to fade away?  You mention that you did the last
reorganization to "hopefully improve the performance"; was there a
noticeable improvement?

If the reorganization did not improve performance, then all you are doing
is reclaiming space by removing deleted records.  You can alleviate that
problem to some extent just by reusing the deleted records.

Regards,
Andy Nolen-Parkhouse



> On Behalf Of Noel Johnston
> Subject: Physical File Performance
> 
> We currently have a file on your system in excess of 60 GBytes and 450
> Million records.
> With the various logical files attached, the file is in excess of 140
> GBytes. It's a bit of a nightmare to reorg and the last time it was
> done it
> took 3 days.
> The suppliers of our software wish to split the file in to multiple
> members
> on the same physical file. This will in theory allow us to reorg the
> file on
> an individual member basis.
> 
> I was wondering does it make sense, will it have an impact on
> performance.
> Or due to the effort involved should we look at a third party product
> for
> doing reorgs in the background.
> 
> Thanks in advance.
> 
> Noel Johnston