This problem (undelete not working) has been visited before. According to
the vendor I worked with on this problem, it is something that IBM didn't
"set correctly" when we upgraded from a prior release (we did v5r2 to v5r4
when it broke). This affects many of the save file based utilities including
undel2. There is a work around that works for some files with some undelete
utilities.
Save the file to a save file.
Restore the file to a work directory.
Run your undelete utility
I just tried undel2 on a problem file and it worked using this workaround.
I was told that I could restore all my files and it "may" fix this problem.
I've heard some feedback that it does not happen with newly created files.
BTW, I like the way you write Chuck. It reminds me of HAL (in a good way).
Good luck.
Mike Krebs
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of CRPence
Sent: Friday, September 07, 2007 9:55 AM
To: midrange-l@xxxxxxxxxxxx
Subject: Re: WRKDBF & V5R4
Since a save of the object.data is not done at a row level, the
speculation that row.data is not being copied into the save file data must
be incorrect. The more likely scenario is that for those data types, the
/externally manifest/ buffer size [e.g. by DSPFFD] for the field does not
reflect the true internal buffer size.
It would seem _more likely_ that the UNDEL2 code has a defect in its
attempt to reverse engineer its access to the data.
The design for those data types was [not the way I would have done it,]
such that, in order to ease access to the languages in a timely fashion, the
request to the database engine for field layouts would offer up a false
definition of the data -- an obfuscation of the truth, to insulate the
caller from reformatting requirements. A seemingly direct access to the
data is in fact indirect, involving an implicit cast to a character string
in the format [DATFMT() specification] defined to either the job or the
query requester. Thus the data is available directly in human-readable
form, rather than the access method having to request a cast from the
internal data representation or reformat by edtcde/edtwrd [as is done for
numeric types].
Regards, Chuck
--
All comments provided "as is" with no warranties of any kind whatsoever
and may not represent positions, strategies, nor views of my employer
Douglas Handy wrote:
<<SNIP>>
Alas, it appears the OS fails to copy the original raw data to the
SAVF in some cases, meaning UNDEL2 is unable to recover the data and
you get default values for the fields instead (typically blank/zero).
Speculation is that this occurs whenever the file includes a data,
time, or timestamp field but I'm not sure if that is always true or
the only cases where the OS does not copy the original data to the
SAVF. The same limitation exists in other tools which use the SAVF
method. I'm not aware of a PTF to address this, though perhaps one
exists.
<<SNIP>>
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe,
or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a
moment to review the archives at
http://archive.midrange.com/midrange-l.
midrange.com
