Re: iSphere source file search issue

On 21-Oct-2015 02:54 -0500, James Evans wrote:

Qsys2.Systables is completely empty! I can only think this happened
when the PTFs were being applied.

FWiW the SYSTABLES is a VIEW rather than a TABLE, so 'empty' can express only a logical condition; i.e. an 'empty' logical view of the data has no relevance with regard to whether the /physical/ data does or does not exist. And that is the reason I offered two queries instead of just one; albeit rather than directing to QADBXREF [only including a comment that that was the intent], I had the second querying QADBXLFI. Although that second query also referenced a logical file instead of the physical, that logical view eliminates the logic of a join that is inclusive of the SYSTABLES logic.

I have sent this down to our infrastructure team who look after the
Ibm i to get this repopulated.

Again, FWiW:

Most likely if the file QADBXREF were [effectively] empty, then that physical [System Database Cross Reference (DBXREF)] file was deleted. Though [at least in the past] so too would have been all the logical files, thus the SYSTABLES would have had to have been re-created since. But that effect is notified of by the QDBSRVXR job via a msg CPF32D1 sent T/QSYSOPR thus implicitly also copied T/QHST which means the History log DSPLOG QHST PERIOD((*AVAIL *BEGIN) (*AVAIL *END)) MSGID(CPF3200) should be able to reveal where to look; notably at what specific job name of the QDBSRVXR job to find the job's [possibly since] spooled joblog.

Hopefully they will review the origin of the problem, and report the issue. So in case the origin might possibly affect others similarly, their report might allow IBM to produce a preventive PTF [or corrective to the code that the may have been responsible unintentionally] for the effect; the effect is sometimes unavoidable\legitimate, but should be extremely rare especially given the impact, and thus the more reason to report. Note that recovery, RCLSTG or RCLDBXREF as corrective to the missing data, also will implicitly destroy [or /wrap/] some historical information that might be of use to investigate the origins; the request to DMPSYSOBJ QDBXREFQ* QSYS 0A C4 taken prior to recovery actions would preserve one specific set of data. Such proactive data collections\preservation could be helpful if reporting the issue; i.e. if reporting of the incident were to result in a followup in an attempt by IBM service\support or dev to scrutinize the failure, rather than their merely dismissing the failure as some wonky [or worse, some typical] incident, presumed [without actual review of evidence] not to be worth investigating for origin and the possible need for preventive\corrective fixes.