The CPF3285 is /logical damage/ that may or may not be manifest on the DSPOBJD. The indication of "damage" via that interface depends on whether the information that needs to be manifest to that interface requires that the _navigation_ of the composite pieces of the DBF to necessarily would encounter the same _logically invalid_ condition that was detected and notified-of in the failed save operation.

The only valid recovery for the condition [other than patching] is stated in the "Recovery" for the message. However, there is optional data recovery that can be performed; e.g. restore from backup and optionally apply journaled changes, or copy existing\current data elsewhere before DLTF as recovery and then copy the data back into the new[ly restored copy from backup]. FWiW, for this logical condition of /damage/, very possibly exists the ability to effect full /object/ recovery as well; i.e. not just data. However without the context of the failure, that is just a guess; typically the issue arises from /member-chain/ issues, such that the prior-member or next-member pointer was lost. Various invocation of DSPFD [e.g. *MBR and *MBRLIST], DSPFFD, DMPOBJ, and possibly DMPSYSOBJ might help to reveal what is the logical condition for which the save code could not properly navigate the composite object. The context for the error msg CPF3285 that was not provided is unlikely to be helpful without also have the listing for the OS program QDBSVPRE which is the probable from-program for that error.

Potentially effecting full recovery:
Save the file with no members
Restore the file to a user library
Perform any authority and owner recovery; e.g. grt w/ refobj
Save each member of the file separately
Restore each saved member to the restored file
Save\Restore each LF of DSPDBR MBR(*NONE) RCDFMT(*NONE) in order
Perform any aut\owner recovery for each LF
If successful, then:
Delete the logical files over damaged file and the damaged file
Move the recovered file(s) in place of those deleted

Regards, Chuck

On 17-Dec-2013 07:21 -0800, rob@xxxxxxxxx wrote:
Ok, so it doesn't appear on * or *PRINT, just *OUTFILE.

On 17-Dec-2013 06:47 -0800, Luis Rodriguez wrote:
Rob, IIRC,
There is always RTVDSKINF. Nevertheless, DSPOBJD has a field
called ODOBDM that is a flag for a damaged object... HTH

On Tue, Dec 17, 2013 at 9:31 AM, <rob@xxxxxxxxx> wrote:

In the joblog I see:

Message . : Damage found on file SYSIXADV in library QSYS2.
Cause . . : The requested operation was not done for file
SYSIXADV in library QSYS2 because of damage to the file. File
SYSIXADV is either damaged or destroyed.
Recovery . . . : Delete and then create file SYSIXADV again. Then
try the request again.

How do I fix this?
Note: Had a drastic power failure Friday.

Also, is there something like DSPOBJD which will say if the
object is flagged for damage?

As an Amazon Associate we earn from qualifying purchases.

This thread ...


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

This mailing list archive is Copyright 1997-2022 by 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.