× 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.



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.


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.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 on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.