SQLRPGLE program fails with SQL0312 error since v6r1 o/s upgrade

I have a small program I am working on to help with a data conversion that needs to be done soon(tm). The program compiled fine on Thursday (albeit with a bug), but in fixing the bug and re-compiling this morning the SQL precompiler rejects the compile citing the following error:
"SQL0312  ...  Position 52 Variable FLTDATA not defined or not usable."

Which is complaining about line 255:
"EXEC SQL FETCH flexConv3 INTO :FLTDATA;"
(note that flexConv3 is a cursor declared from a host variable via a PREPARE statement.)

I am certain that the FLTDATA variable/field is defined clearly at the top of the program, and there are no scope problems such as different procedures/subroutines/source members involved:
"D FLTDATA         S          32767A   VARYING"


I tried to re-compile the program from Thursday's source and I get the same problem. The only change since thursday was an i o/s (os400/iSeries/etc.) upgrade to v6r1. Does anyone know what changes were introduced that cause the above FETCH statement to fail to recognise the variable declaration?
Paul-BaileyAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

tliottaCommented:
Just a quick question -- Did you try compiling for the earlier TGTRLS(*PRV)? Beyond that, please run WRKPTFGRP and show us the various group levels since the upgrade. The cume and DB2 group levels would be most important.

Tom
0
Paul-BaileyAuthor Commented:
Sorry, I should have mentioned straight off: Thursday the TGTRLS was at v5r4 and now (since the upgrade) the TGTRLS is set to *PRV. Which confuses me even more!

The WRKPTFGRP output is in the code snippet attachment. The cume and DB2 are here:
SF99610               CUMULATIVE PTF PACKAGE C0047610               10047  Installed
SF99601               DB2 FOR IBM I                                                                    13  Installed


 

PTF Group             Level  Status        
SF99610               10047  Installed     
SF99609                  58  Installed     
SF99608                  16  Installed     
SF99601                  13  Installed     
SF99562                  11  Installed     
SF99356                  17  Installed     
SF99354                   5  Installed     
SF99353                  12  Installed     
SF99352                   3  Installed     
SF99350                   5  Not applicable
SF99187                  12  Installed     
SF99115                  12  Installed

Open in new window

0
Paul-BaileyAuthor Commented:
After some extra reading and a bit of banging-my-head-against-a-wall, a colleague pointed me to the SQL reference manual v6.1 page 1204, which gives the following max sizes:
 
Maximum length of CHAR (in bytes)
32765
Maximum length of VARCHAR (in bytes)
32739

Changing the definition of FLTDATA to 32000 instead of 32768 allowed the program to compile.

I am happy that the problem was solved, but can anyone explain how the program compiled last week before the upgrade to v6r1? The variable sizes were apparently the same in v5r4 as well!
0
tliottaCommented:
I do see this statement marked with "change" marks:

[Start of change]The SQL precompiler accepts variables defined as VARYING(2), but does not support VARYING(4). The LEN keyword is recognized, but only lengths up to the SQL limit for the data type are accepted.[End of change]

This is found here: http://publib.boulder.ibm.com/infocenter/iseries/v6r1m0/index.jsp?topic=/rzajp/rzajpdeclaringirpg.htm

I suspect that the pre-compiler simply tightened up some loose ends. A RPG program variable wouldn't actually be a SQL variable, so I don't see why it'd be a problem to FETCH into a larger area. I'm not at all clear why compiling to a previous target release wouldn't work.

Tom
0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
Paul-BaileyAuthor Commented:
I guess you are right. I'll give the points even though you didn't give the full solution.
0
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Mainframe Languages

From novice to tech pro — start learning today.