Paul-Bailey
asked on
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/sou rce 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?
"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/sou
"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?
ASKER
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
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
ASKER
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!
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!
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
I guess you are right. I'll give the points even though you didn't give the full solution.
Tom