× 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.



That might well be it, Trevor. I just deleted characters from columns 1 - 7 (they all looked blank in LPEX, but...), so now the double-dash is in columns 1 and 2 for each line of the whole comment block. RUNSQLSTM appears to have run w/o error.
I'll post again if this reoccurs.

Many thanks!
-- Michael

-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-
bounces@xxxxxxxxxxxx] On Behalf Of Briggs, Trevor (TBriggs2)
Sent: Wednesday, November 06, 2013 8:53 AM
To: RPG programming on the IBM i (AS/400 and iSeries)
Subject: RE: Too many comments in QSQLSRC?

Are you absolutely sure that columns 1-7 are blank and some errant non-
displayable character didn't sneak in there somewhere? That could
explain why deleting some comment lines works and also why cutting-and-
pasting to iNav works.

Trevor Briggs
Analyst/Programmer
Lincare, Inc.
(727) 431-1246
TBriggs2@xxxxxxxxxxx
-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Koester, Michael
Sent: Wednesday, November 06, 2013 8:35 AM
To: RPG programming on the IBM i (AS/400 and iSeries)
Subject: RE: Too many comments in QSQLSRC?

Hi Alan.
The spool file shows: SQL0901 50 [Record] 1 Position 1 SQL system
error.

I've been through the "split it down to bare components" routine, and
it appears to be successful with each, and it is successful with the
entirety of the CREATE OR REPLACE VIEW with a three-line header comment
block. It is only when I add several more comments that it gets pushed
over the edge and indicates a failure:
RUNSQLSTM mkoester/QSQLSRC V_PRFSPEED COMMIT(*NONE)
Receiver value too small to hold result.
SQL system error.
Ownership of object GPTFLST in QTEMP type *USRSPC changed.
RUNSQLSTM command failed.

Each comment line is blanks in columns 1-7, and has two hyphens in
columns 8 and 9.

-- Michael

-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-
bounces@xxxxxxxxxxxx] On Behalf Of Alan Cassidy
Sent: Wednesday, November 06, 2013 8:08 AM
To: RPG programming on the IBM i (AS/400 and iSeries)
Subject: RE: Too many comments in QSQLSRC?

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



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

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.