Re: How the SQL Server World Lives

Interesting. How can one determine what was actually damaged? It's been a long time since I've seen a system with a damaged object, and all I can recall is that it said it was damaged; there were no specifics.

And assuming that some catastrophic disk failure damaged just the *OIRS, what would DSPOBJD do when it tried to display the save history for an undamaged object?

On 1/31/2013 7:22 AM, CRPence wrote:

On 30 Jan 2013 16:59, Peter Dow wrote:

That makes sense except I'm a little confused because you said

"Object Information Record (OIR) which is separate part of the
composite *LIB object"

and then

"is not an update to the headers of the objects, not even the *LIB
object."

So if the OIR is a part of the composite *LIB object, then how can
the *LIB object not be updated?

The second could have been written instead as "is not an update to
the headers of the objects, not even the Context object." For some,
that alone resolves the apparent contradiction. For anyone else...

I tried to explain that apparent contradiction was understood, that
an update does happen "during" a save, though only by user request and
"after" the save from the perspective of the OS [which I thought was
important to imply how the save was "just reading" the unchanged image
of the object to dump to the media]. I intended to downplay the role of
the updated *OIRS however, without actually trying to explain why that
update is almost irrelevant. Irrelevant unless the claim had been that
OIR had been corrupted by the save activity. However almost no
explanation was given about what type(s) of damage\corruption had been
encountered, even though I had asked in order that I could better
explain the particulars for the failing scenarios.

The role of the OIR can be downplayed first because the *LIB is quite
unique in that regard, and second because the *LIB objects are generally
a minuscule portion of the overall number of objects in a save request,
and third because when a *LIB object is saved it is the *OIRS of QSYS
that gets updated. Yet the claim had implicated all objects. The claim
was that the save can damage objects "because the save is operating on
both the object header and the data portion of the object.... a save is
more than just reading the data portion of the object, it updates the
object header and other internal structures while it's operating."

So other than the *OIRS as the specific "data portion" of a *LIB, I
was trying to ferret out what was the implied /update/ alluded as being
made to object headers [and data portions]. It seems a baseless claim.
As a space object, the *OIRS can only ever be marked with "partial
damage", and effectively only due to a disk error [or a Storage
Management error which is effectively the same].

Anyhow, only LIC can mark an object as damaged. An /object header/
is the domain of the LIC [with a limited number of methods the OS can
use to effect any updates] and the *OIRS being a "space" can be written
to directly by the OS [in this case the Save feature via an interface
provided by the Librarian feature] with effectively no limits. The LIC
object header of the *LIB is the /LIC context/ object, and the *OIRS and
*QDIDX are both OS created objects as part of the composite *LIB; of
these, only the *OIRS would be written to, with the updates to the
"Save/Restore information" that corresponds each object that was saved
in the all-but-complete save request, and only per UpdHst(*YES).

Regards, Chuck

On 1/30/2013 12:42 PM, CRPence wrote:

On 30 Jan 2013 10:10, Peter Dow wrote:

What about this information (seen with DSPOBJD)?

Save/Restore information:
<<SNIP>>

Isn't this stored in the object header? Doesn't the save process
update it?

On 1/30/2013 9:04 AM, CRPence wrote:

<<SNIP>> Even the /update history/ which, if included, is
written in a separate location from the object; i.e. in the
OIR, and after the object is saved. <<SNIP>>

That is the /history/ information [UPDHST(*YES)] that is in the
Object Information Record (OIR) which is separate part of the
composite *LIB object, and that is updated after the save of the
object. The update is to the *OIRS [OIR space] object only. So as
part of a SAVLIB the saved library object with its OIR will save
the unchanged image; i.e. the image before a change to update the
history. However, the write activity for that history will be
before the SAVLIB request returns control to the user; that is
post-save [from the perspective of the OS] and optional [as
requested by the user], and is not an update to the headers of the
objects, not even the *LIB object.