That message has nothing to do with comments.
Somewhere in your 80 lines of code, your statement attempts to calculate or concatenate a derived value (one computed from other columns) and put the result into a new statement-defined column, like a sub-query.
What I do with things like that is break it up into chunks you can analyze one at a time. Even if my plan is to end up with a complex 80-line View, for example, if it includes a common table expression (WITH clause), I define it as a temporary file of its own in QTEMP, and then use that for the other one.
That way you find out where your problem is.
RUNSQLSTM creates a spool file that tells you where it is that SQL thinks the error is. You might check that first. BUT I still suggest the stepwise approach first, as you can more easily check the results from each "discrete" part of the statement more easily.
--Alan
-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Koester, Michael
Sent: Wednesday, November 06, 2013 7:40 AM
To: rpg400-l@xxxxxxxxxxxx
Subject: Too many comments in QSQLSRC?
(yet another episode in "Novice [mis]adventures in SQL") It seemed like such a good idea to have my Create View coded up in its own source member in QSQLSRC, so I could have that source member moved to our production repository of code, and SysAdmin could create production objects from that member with RUNSQLSTM.
And it also seemed reasonable that I could put a comment block at the top of the source member where the next poor schmuck could "check out" the source and get a sense of the method to my madness before laughing at my code.
So I have this source member with a somewhat complex Create View statement, running roughly 80 lines. My comment block was about 50 lines, including the updates history log structure, etc.
My RUNSQLSTM fails with a non-descript "Receiver value too small to hold result." (MCH1210).
I rip out all but 3 of my comment lines, and everybody's happy - no harm, no foul, no error. I thought about reinserting comments one by one to find the exact threshold of doom, but didn't.
Is this documented somewhere, that while one might expect the RUNSQLSTM to skip past any source line beginning with "--", that it might tire of skipping and trip? I did try to wrap the whole comment block thing in /* ... */, so it wouldn't have to deal with all the dashes, but that didn't work either.
So it all goes to production with three lines of comments, one of which being:
-- Add more comments at your peril!
Running OS 7.1 here.
One other item of note: The MCH1210 did not prevent creating the LF object, but experience from earlier this week tells me that when this happens when SysAdmin runs the RUNSQLSTM, the production object is flawed in some way, and fails to get created in a RSTLIB operation.
Michael Koester
Programmer/Analyst
DataEast
--
This is the RPG programming on the IBM i (AS/400 and iSeries) (RPG400-L) mailing list To post a message email: RPG400-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives at
http://archive.midrange.com/rpg400-l.
--------------------------------------------------------------------------------
Confidentiality Notice: This email may contain confidential information or information covered under the Privacy Act, 5 USC 552(a), and/or the Health Insurance Portability and Accountability Act (PL 104-191) and its various implementing regulations and must be protected in accordance with those provisions. It contains information that is legally privileged, confidential or otherwise protected from use or disclosure. This e-mail message, including any attachments, is for the sole use of the intended recipient(s). Any unauthorized review, use, disclosure or distribution is prohibited. You, the recipient, are obligated to maintain it in a safe, secure and confidential manner. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. Thank you.
--------------------------------------------------------------------------------
midrange.com
