Re: [EXTERNAL] Re: Missing SYSIBM.SYSDUMMY1 object

On 21-Sep-2016 12:24 -0600, Maassel, John R. wrote:

I was able to restore the object and rebuild the view.

Removal of the dependency on the SYSDUMMY1 VIEW using the row-values clause might be preferable. There are restrictions however, for which doing so might not be desirable; i.e. on some releases, there would be no support to use native I\O [e.g. CPYF] or CQE queries [e.g. RUNQRY] against the [join] VIEW that getss created with row-values clause rather than created how the VIEW [that failed to restore due to the missing dependency] is being created presently, by referring to the dummy view.

FWiW, I would prefer not to refer to either of QSQPTABL in QSYS2 or SYSDUMMY1 in SYSIBM in a user-created VIEW, because the OS presumably must reserve the right to DROP those files using CASCADE to effect any recovery of the installation; I coded the install\creation of the former, but I really do not recall the details. That is because rather than a logical\conceptual reference that might be established in other DB2 variants, the SYSDUMMY1 is a named *object* [as is the QSQPTABL TABLE] for the DB2 for i, so dependencies are [in essence] literal rather than figurative. I probably would create a one-row TABLE for an application or the system generally, if desirable\necessary; avoids any possibility the OS [during install or any other recovery actions] would drop my VIEW as the effect of a cascaded DROP.

Will upgrading from 6.1 to 7.2 replace any other missing objects?

The operating assumption should be that an upgrade will restore and\or create the necessary objects. Whatever was the current situation for which the object(s) went mission should be considered anomalous -- as another followup reply suggests is presumed.

That assumption holds, until it does not :-Q for which the most likely\valid conclusion is that there was some defect or usage problem for which the objects either were never made available or were [accidentally] made unavailable. Determining which and when, then becomes the topic; but the feasibility and value in such debug activity may render such a topic moot, per having called any necessary recovery program(s) and\or other recovery actions that might hinder such review; e.g. RCLSTG SELECT(*DBXREF) may be a prerequisite to the success of the CALL QSYS/QSQSYSIBM, or as Rob suggests, the former may by itself effect the latter, as the near-final operation. Such recovery would be typical for most. I instead would prefer to attempt to determine origins of such problems, in hopes of obtaining preventive for my next iteration, as well as for the sake of others in hopes they never experience the same; i.e. hoping the problematic situation might be prevented\preventable [or perhaps made more conspicuous as having arisen, in paths determined to be ], instead of only ever getting _rectified_.