On 30 Jan 2013 08:07, Dan Kimmel wrote:
<<SNIP>>
It scans through the objects in the library (or subset) and checks
for status of 'D' or 'P'. Is this status updated before a save is
attempted? Or does the save itself detect the damage and update the
status?
The Object List APIs [and DSPOBJD which uses the OS equivalent to the
APIs] just ask the object if the object is already known to be damaged;
a MATSOBJ Materialize System Object for simple object types. In rare
cases, for when an object handler [for complex objects; e.g. database
*FILE] must navigate the object in such a way that a composite piece of
that object not previously detected as damaged, some portion of the
object or data may get detected during that limited navigation [limited
to effectively getting size information], and only then is the object
marked as damaged. The Save feature [LIC Dump feature] must navigate
the object and any data portions more thoroughly than just asking for
the size of the composite pieces, and thus an upcoming save could still
detect damage not visible to the Object Listing request. And for
whatever the Object Listing request informs of prior known damage, the
Save feature will already omit those objects from being saved so they
can not cause a problem for the save request. Thus such requests will
serve little purpose except in the [hopefully] rarest of occasions, to
do nothing but perform unnecessary work at the cost of CPU and faulting;
i.e. generally unproductive request to preceded a save [except for
persistent cases of damage like Rob noted for *MTGCOL... but then, the
service provider should be working to resolve the problem rather than
having the customer deal with circumventing the issue].
