Re: How to re-org an empty file -- MIDRANGE-L

Thanks Chuck; I suspected something like that or someone would've used it to create an undelete. Interesting background on why IBM never implemented an undelete...

On 3/30/2012 1:04 AM, CRPence wrote:

A RRN undeleted via an update [I\O request via the QDBUDR] does not
recover the old data. That is why the SAVOBJ technique is used to
locate and recover data from [fixed-length] deleted records.

The /update/ method provides as input, the desired row image. So
although an uncleansed prior /delete/ [i.e. the DENT byte, the Deleted
Entry indicator, perhaps being all that was changed to effect the
/deleted/ row while leaving any record-data unchanged] might have been
the effect, whatever data may have remained there is replaced by the new
row image; default values are generated for any fields that were not
provided as part of the desired update-to row image.

Note that the variable portion of the record [i.e. the "var SID", the
data segment(s) where the VarLen row data is stored] already may not be
available in a deleted row. And if a secure\cleansed delete is
available and used, so too the data even for the fixed portion would be
unavailable; i.e. the SAVOBJ technique would have even more limits in
effectiveness as a means to recover row data from a deleted row.

I recall there was a long outstanding request to expose a true
undelete method, but I do not think that was ever given much pull. The
complexity due in part to undelete not having been a consideration in
initial designs [e.g. accpth maint, varlen, and obviously ReuseDlt] and
a competing desire for secure deletes [perhaps as a file attribute, set
in each dataspace] made that unlikely; but _if_ implemented, would
surely be as an /insert/ of the recovered data, and not limited to just
some very specific small subset of files, and so very costly to make
happen. Backups and journaling were always considered sufficient to
recover any deleted row data. And perhaps the lack of undelete gives
great incentive to start journal of the physical files; a long
outstanding desire that customers would implement, for which
enhancements in managing receivers and performance of journaling gave
further hope.

Regards, Chuck

On 29-Mar-2012 21:43 , Peter Dow wrote:

"an update to that record makes that row\RRN become an
active\undeleted record."

Can that be used to undelete a record and recover the data that was
in it?

On 3/29/2012 12:34 PM, CRPence wrote:

<<SNIP>> Then because a deleted row can be positioned-to like any
other record when employing "direct" positioning requests, as with
OVRDBF POSITION(*RRN rrn), an update to that record makes that
row\RRN become an active\undeleted record. That capability allows
data copy from an active row to a previously deleted row, as
implementation for reorganizing to compress deleted rows [from the
lower RRN of the dataspace to the end, such that the database can
eventually be truncated of only since-deleted RRNs].<<SNIP>>