Re: CPF3285 Damage File QAYPSYSTEM in QMGTC

[CRPence <CRPbottle@xxxxxxxxx>]

Jim Franz wrote:
> For 2nd month in a row customer's Save System halted with
> CPPF3285  on a damaged file QMGTC/QAYPSYSTEM.
> I did a RCLLIB on QMGTC thinking it would solve the problem.
> <<SNIP>>

  The CPF3285 is an error indicating that there is an OS [not LIC] 
detected [thus not officially "damage"] detected with the database 
*FILE object; typically in navigating to a member or a dataspace of 
a member.  The origin for those errors are not likely to be 
corrected by RCLSTG OMIT(*DBXREF), nor any other "reclaim" function; 
most typically by DLTF and re-create or restore [and the authority 
recovery for the object].  FWiW IIRC the most common origin for the 
condition was the database losing track of the number of members in 
the file; i.e. the *FILE suggested there were two members, but there 
was only one member... and the code /assumes/ the number is correct, 
and the failed assumption [brought on by mch3601 for the next-point 
not being set] is manifest as the CPF3285.

  I do not recall what RCLLIB claims to do, but I recall looking at 
the code to find it did effectively nothing as far as I could infer; 
at least not as much as what was implied.  IIRC the claims of the 
command were something like that it would validate and purge orphan 
OIR, but that the code and effect was only the latter; i.e. the 
*OIRIDX and *OIRSPC [or whatever types; see DMPOBJ of a *LIB] were 
not well validated and reassigned.  Point is, RCLLIB is not expected 
to correct any problems with a database file; except possibly its 
OIR [object information record] which is some of the detail for 
DSPOBJD, and I have my doubts of what it can fix since the only 
cases where its use seemed appropriate, no relief was experienced in 
its invocation.

Regards, Chuck