On 11-Jun-2014 12:43 -0500, Koester, Michael wrote:
All's good. Until RSTLIB copies that production object to our test
library. Throws MCH1210. I create the <SQL VIEW> object into the test
library from the production source with RUNSQLSTM, and it's happy -
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.
This SQL View is created from joining a physical file with a
couple other views. I verified from the joblog that the dependent
views had been successfully restored prior to the attempt to restore
the problem view. Incidentally, the other five views (two of which
join to another view) restored without error.
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.
The dump from the RSTLIB job shows this:
<ed: reformatted as symptom kwd string>
msgMCH1210 F/QSQVTCHG FM/QSQVTCHG FP/OLD_FIXVIEW stmt/4223
The code that re-parses the statement looking for /text change/
requirements, i.e. to update the /statement text/, is failing and the
error is resignaled to the database restore program causing the DB to
properly fail the restore of that object. The circumvention of using
the CREATE VIEW is a good approach until a fix can be made available.
The fix may be in the CREATE VIEW, or may be for the /VIEW Text Change/
program QSQVTCHG; if the former, the correction is not preventive for
the restore operation, but for the create operation, and thus the
recovery would require creating the new object and obtaining the save of
the corrected object.
We're running 7.1 with TR7. If you're interested in the prior
discussions from last November, they're in threads, "Too many comments
in QSQLSRC?" <http://archive.midrange.com/rpg400-l/201311/msg00024.html>
and "Will Nested views create issues for RSTLIB?"
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.?
Suggestions for making RSTLIB behave?
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.