× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



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?" and "Will Nested views create issues for RSTLIB?"

Suggestions for making RSTLIB behave?

Michael Koester
Programmer/Analyst

DataEast


As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.