RE: Too many comments in QSQLSRC?

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