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

Member_2_276102

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

Paul-Bailey

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

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

Paul-Bailey

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!

ASKER CERTIFIED SOLUTION

Member_2_276102

membership

This solution is only available to members.

To access this solution, you must be a member of Experts Exchange.

Start Free Trial

Paul-Bailey

ASKER

I guess you are right. I'll give the points even though you didn't give the full solution.