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:
<<SNIP>>
In the joblog I see:
CPF3285
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.
<<SNIP>>
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?
midrange.com
