RE: Too many comments in QSQLSRC? -- RPG400-L

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

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

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

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.

-----------------------------------------------------------------------

---------

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