How a dynamic view manages derived objects
Nonshareable and unshared derived objects typically consume the most disk space in a view’s private storage area.
In addition to view-private files, a dynamic view’s private storage area
contains derived objects built in that view by clearmake (and,
on Windows®, omake).
When a derived object is created, its data container file and its configuration
record are stored in the view. The first time the derived object is winked
in to another view or promoted to the VOB, the view interacts with the VOB
as follows:
- The configuration record is moved to the appropriate VOB. If the build script creates derived objects in several VOBs, each VOB database gets a copy of the same configuration record.
- The data container is copied (not moved) to the VOB’s DO storage pool.
If the DO was winked in by a clearmake or omake build,
the original data container remains in view storage, to avoid interference
with user processes that are currently accessing the data container. If the
DO was winked in with the winkin or view_scrubber –p command,
the data container in the view is removed after it is promoted to the VOB
storage pool.
From time to time, you mkight find it worthwhile to remove redundant containers from views with the view_scrubber utility.