RE: Questionable practice in file handling in CL

I had an old article from at least a decade or two ago that said that this
was pretty much obsolete. It agreed that it did used to be a concern. And
previously it was recommended on a large file initial population to remove
the logical files and add them back at the end. But it was no longer a
concern as of V (something or other) of the OS.

However, there are those who beg to differ and say they have even some
recent experiences that this is not totally resolved.
One person in this thread did notice a "slight" increase in run time on
large files but their most recent comparison was at 6.1. And it was not
noted if they included the build time of the access paths of the LF's in
this run time.
One person noted his concern about paying the penalty later with a delay
rebuild on the access paths and if it was beneficial with all combined.
One person noted that changing the maintenance on the LF's to deferred,
adding the rows and then changing the LF's back to immediate (with
parallel jobs) was faster. Perhaps an access path rebuild is more
efficient than maintaining the access path upon the addition of each row.
This person did not mention when they had this experience however. Perhaps
hardware and OS have changed since then?

I keep thinking back before we saved access paths on our saves on how we
were literally locked out of some files for almost a week during a restore
while it was rebuilding access paths. So, these access path times can be
substantial. So deferring them until needed may not always be the most
popular idea. IBM changed the defaults on saves to save access paths
since then. Too many people got burned. That and media speed and volume
has substantially increased since then.


Rob Berendt