Re: MCH1210 in RSTLIB (Receiver value too small to hold result.)

On 11-Jun-2014 12:43 -0500, Koester, Michael wrote:

<<SNIP>>
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 -
no errors.

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
T/QDBRSPRE x/0385

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?"
<http://archive.midrange.com/rpg400-l/201311/msg00016.html>

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.