On 14 Feb 2013 08:37, Vernon Hamberg wrote:
<<SNIP>>
Maybe the library object HAS the size, and maybe that is where
DSPOBJD goes - again, I don't know. But if you have a large system,
you're still going to have a long time to process things.
<<SNIP>>
The size is inquired of the object header [for simple object types;
e.g. user spaces]. A system pointer must be obtained to the object,
from which the MI MATSOBJ requests the LIC to return the object size
from the LIC header of the object. For complex objects [consisting of
multiple object types to represent one external object type] the owning
feature of the object would be asked to combine the results of multiple
MATSOBJ performed across each of the *SYP [system pointers] that entail
the sub-component-objects of the external object; e.g. a database *FILE
will add up the size of the *FMT, *DBDIR, *MEM, *QDDS, *FILE, et al to
give a full accounting of the "size" of the object.
I suppose the system could effectively, for every SM operation that
affects the size of a permanent object, update some database which is a
repository for that size information. IMO a better idea would be to
leave the size to inquiries, but implement the *LIB, database *FILE, the
record format, and directory objects as capable of being queried by the
database; effectively ridding of the catalog, and expanding the
functionality of the catalog across the system.
