Re: SQL views missing after Cumulative PTF's applied

OK, so clearly not "views missing" then. Any implication that the refresh of the *DBXREF data will magically re-create missing objects should probably be avoided. AFaIK that is [quite close to absolutely being categorically] false; e.g. the DBXREF does maintain the [potential] capability to rebuild its own database files QADB* in QSYS without re-installing them, per CPF32D3 "System file &1 in &2 created." and CPF32D4 "System file &1 in &2 was not created."

Would be nice to know what exactly was the message that deemed the files "unusable", esp. given that the request to RCLSTG SELECT(*DBXREF) is designed to refresh data from existing objects, not to "fix" the objects themselves; i.e. many conditions that would impact an application could just as well similarly impact the ability of that refresh request to access the file. One exception being any database *FILE objects for which a pending non-commit /database recovery object/ exists, such that the database component-specific pre-processor for the standard /reclaim storage/ (RCLSTG) feature would effect the pending /database recovery/ [see CPF3245 "logical damage"] processing against those objects; only non-commit recovery, else the recovery for pending commit actions instead would come about from the forced rollback or commit when removing those commit definitions... as a pre-requisite to the reclaim request.

So anyhow, it is not the refresh of the *DBXREF data that would effect any recovery, but the actions of the database reclaim feature that precedes the refresh of the System Database Cross-Reference data which could knowingly be unaffected by pending recovery which is an issue that an application might encounter. A distinction with a difference, even if not conspicuous to anyone unaware of the design of the [database portion of the] reclaim feature and the database recovery feature. Regardless, nothing about a PTF application should necessitate that action as a side effect; although possibly per explicit requirements noted in Special Instructions, though most likely only for some recovery aspects of a preventive but non-corrective PTF, for those applying the PTF specifically in response to having knowingly or only possibly to have experienced the defect that is since prevented by the application of that PTF.

Regards, Chuck

On 26 Aug 2013 12:29, Dan Kimmel wrote:

Yes. I'm going back through my mental notes. The LF object was there
but was unusable. Did not throw a file not found exception, which
would have precluded the job starting, but threw an ugly message in
the log every time it was referenced. Error was caught but unhandled
in our code which kept the code from doing its job, but didn't kill
it. RCLSTG *DBXREF fixed it.

CRPence on Monday, August 26, 2013 2:11 PM wrote:

On 26 Aug 2013 09:59, Dan Kimmel wrote:

We've had the LF *FILE objects associated with views disappear
when our customers have applied PTF's on V7. RCLSTG
SELECT(*DBXREF) gets them back.

If true, there is something seriously wrong. The refresh of the
DBXREF should not be necessary to recover any objects, even if
that action could or might effect such a recovery. If the actions
by the system had maintained the information necessary to recreate
the user-created VIEW file objects that were dropped by the CASCADE
effect [be it stored in a /database recovery object/ or a row in
the *dbxref], then whatever effected the cascaded deletion should
be performing that object recovery *inline* to the same
procedure\processing; i.e. no explicit separate\later recovery by
the customer should be required. Such an expectation by IBM should
be recognized as nonsense; easily inferred as a defect vs
working-as-designed.