Re: CPF3285 Damage File QAYPSYSTEM in QMGTC

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