×
The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.
On 29 Jan 2013 14:33, Jim Oberholtzer wrote:
It can because the save is operating on both the object header and
the data portion of the object. In the cases I have run into either
the save was canceled manually with an *IMMED option, or save while
active checkpoints were in limbo, and a couple of cases were the
object was locked. Remember 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.
What updates would be made to the objects being saved? I am aware of
none. Of course, actual changes should be reflected in the Last Change
Date\Time which is stored in the object header. I do not expect many
objects [types] saved will show their change date to match when they
were just saved.
A save must navigate an object, but the OS save [and LIC dump]
feature should not update the object being saved. I accept there may be
some rare circumstances; e.g. I was flummoxed when Database Save chose
to write a corrective object change to an index space during saves
[mostly because of the negative impacts on restores and for the
differences between that and a the next save], but that was the first
ever I was aware of a write to an object being saved object by DB Save.
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. Even the post-IPL LIC CF /first touch/ update is not done during
saves; for sure not to the DB portion, well... since that issue was
corrected after being broken for awhile, because that feature adds to
storage taken during the save and is not returned until the next IPL.
All of the errors I have encountered have been on data objects
(tables, indexes, etc) I have yet to see it on V7, rarely on V6,
and often enough on V5R4 to be concerning.
Specifically what errors transpired may help to clarify.
On 1/29/2013 4:16 PM, Glenn Gundermann wrote:
I understood it that a save could detect a corrupt file, not that
it would be the one corrupting it.
Assuming "corrupt" means "damage" in the DB2 for i vernacular, then
that is an essentially correct understanding. A terminated save might
however, leave a database file object "logically damaged"; so it is not
the save that damaged the object, but the termination of that save. As
noted in a prior reply, that is unexpected in but a very few scenarios.
The Save feature might do any of: (1) See that an object is already
marked "full damaged" or "soft damaged" and implicitly omit the object
from the save; i.e. detect the object is already damaged (2) Perform
some navigation of the object\data for which damage is set [for the
object or data] by a LIC feature; i.e. detect that the object is damaged
and needs to be indicated as such, and then that save would be
terminated by the OS due to a "damage set" condition (3) Start save of a
composite that requires a Database Recovery Object and then the save
terminated [by external action; power loss, EndJob, storage full] in a
way that the Database Recovery remains pending, thus leaving the file
"logically damaged"; for storage full the locks remain held until the
Save process is signed off\ends (4) anything for which any other
[non-DB] object handler might detect or leave an object "logically damaged"
midrange.com
