Our shop has a job that is run every so often to refresh our test library with recently saved production data. The job runs the CLRLIB and then the RSTLIB commands, to copy the production data files from tape. (I believe the data got onto the tape with SAVLIB, but have not verified that). This morning, I was told that we got a MCH1210 near the end of the RSTLIB process, on restoring one of six sql views I created last fall. Operations asked that I fix this, and I thought I did about a month ago.
You may recall I encountered this in Nov 2013, where I hit the MCH1210 when creating a view with RUNSQLSTM. I've since come to believe that the MCH1210 is a bit of a red herring: If I put an "empty comment" in the CREATE OR REPLACE VIEW source (i.e., a line of code with a dash in columns 1 and 2, followed by blanks to the end of the line), I get MCH1210 when I run RUNSQLSTM. Remove the empty comment line, or add any non-blank character somewhere after column 2, and RUNSQLSTM executes without error. Odd, huh?
So I fixed the source (no more empty comments), and had sysadmin install the source into production, and he ran RUNSQLSTM to create the production object. No errors. All's good. Until RSTLIB copies that production object to our test library. Throws MCH1210. I create the object into the test library from the production source with RUNSQLSTM, and it's happy - no errors.
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.
The dump from the RSTLIB job shows this:
5770SS1 V7R1M0 100423 IBM i DUMP
DUMP TAKEN FOR UNMONITORED ESCAPE MESSAGE
.MESSAGE ID- MCH1210
.MESSAGE FILE- QCPFMSG LIBRARY- *LIBL
.SEVERITY- 40
.MSGTYPE- 0F
.SENDING-
..PROGRAM- QSQVTCHG
LIBRARY- QSYS
..MODULE- QSQVTCHG
..PROCEDURE- OLD_FIXVIEW
..STATEMENT- 0000004223
.RECEIVING-
..PROGRAM- QDBRSPRE LIBRARY- QSYS
..INSTRUCTION- 0385
.MESSAGE-
Receiver value too small to hold result.
.MESSAGE DATA-
END OF DUMP
* * * * * E N D O F L I S T I N G
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
Suggestions for making RSTLIB behave?
Michael Koester
Programmer/Analyst
DataEast
midrange.com
