So the CREATE VIEW gives joy [though possibly some issues even with
that], not so much the restored VIEW. Any issue with CREATE VIEW
should be treated as a separate issue from the Restore Object activity,
until shown otherwise. At least the specific failure information for
that activity should be presented separately; and clarified if the
apparently same issue from 2013 having gone unreported\unresolved.
I did not report the problems I was having last November, mostly because at the time we were not current with PTFs and I anticipated getting TR7 -- hoping that the OS update would miraculously fix things.
When a VIEW is created the /statement text/ is maintained in the
*FILE object and in the catalogs. When the VIEW is restored to a new
library, the qualified table-references must be updated to reflect the
new schema [library] name.
I don't know if "nonqualified" table names would need to be updated or not, but for the most part we don't qualify in our source code. We rely on the library list for that, and that is the case here.
I did not go back to review those topics, but I suppose the current
anomalies with CREATE VIEW are /the same/ as those in the past, and
that issue was never reported, diagnosed, and prevented with a PTF.?
I did not submit a PMR. What I presumed to be the solution for my immediate issues was
1) becoming more familiar with what works and why (even though this MCH1210 for the empty comment was bizarre, since it didn't appear to bother anyone else but me, I just fixed my source), and
2) thinking that when I got the production object to create w/o error, I expected the RSTLIB would then also run correctly. Silly me, I know.
Reporting the error(s) as defects; providing necessary
information\steps for the development to re-create the issue and thus
to investigate corrective [code change] actions.
Sounds like I need to get the IBM folks involved. I'll see if I can get some support here to do that.
Thanks again. I appreciate your input.