Re: CPF5035 on 2nd call of SP from RPGLE

On 21-Apr-2017 07:30 -0500, MichaelQuigley wrote:

On 20-Apr-2017 06:19 -0500, Paul Bailey wrote:

The cursor is created by the ALLOCATE in the RPGLE (instead of an
OPEN) and then closed by the RPGLE after use. I think my initial
worries that RPGLE was part of the problem were incorrect and the
issue is actually with the FINAL TABLE implementation in "DB2 for
i". RPGLE handles result sets from stored procedures using SELECT
statements with the same ALLOCATE routine fine, and the stored
procedure I was using for the INSERT also failed with the same
problem when called through a JDBC connection.

Maybe I've missed and this has already been covered in the thread,
but the CPF5035 is caused by a mis-match in data types. The most
common cause I've seen for this is not declaring a numeric as a
signed-numeric field--whether or not the data can actually be
signed, you must declare it as signed. The second-level text on the
error will tell you the field name and give an error code which
should clarify what is actually wrong.

The issue from the OP is an invalid varlen portion for a VARCHAR value; [most] likely cause, that some character data is mis-perceived by the database code to have been given as the amount of variable-length data.

This may have been covered before, but does the INSERT actually
happen or is the error before that? Knowing this could help narrow
it down, too.

FWiW:

From the OP, the minimal provided context of the error msg CPF5035 RC14 [conspicuously absent is the from\to programs] suggests that the issue is with the insert portion/phase of the SELECT [from INSERT] statement; i.e. the mapping error occurs on RRN=0. Thus implying that the INSERT failed.

But, from the given source, all of the relevant definitional and actual work appears defined entirely within the SQL procedure [source]; though the field name mentioned was not visible in any source, and no DDL was provided. Also mentioned, was that just twice calling the SP from Run SQL, reproduced the issue; i.e. sans SQLRPG invocation. As such, the RPG source should be immaterial, and thus the topic probably not even germane for this list.

Seems likely therefore, that there is an issue with either the compiled ROUTINE or [more likely] the DB2 for i SQL RunTime; something that would need to be reported to a service provider [option the OP suggests is not available] or circumvented. I suggested the latter, plus testing the code on v7r3 to see if the problem persists or perhaps a correction has been made that allows the code to run there without error. The OP did not give all the sources required for a standalone testcase, such that a reader of the message might be able to do that [also], so I suggested that using pub400.com might be an option; while a conjured DDL might suffice for someone else to reproduce, no inference could be made from an inability to reproduce, without knowing that the specifically just-created TABLE of known DDL had exhibited the issue on the v7r1 testing.