MIDRANGE dot COM Mailing List Archive



Home » MIDRANGE-L » January 2013

Re: How the SQL Server World Lives



fixed

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.







Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2014 by MIDRANGE dot COM and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available here. If you have questions about this, please contact