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_.
midrange.com
