Hi Jon

Memo to Users for 7.5 has information on this -

In IBM i 7.5, support for a native SQL BOOLEAN data type was added to Db2 for i. Since the BOOLEAN data type matched the RPG indicator data type, the RPG precompiler was changed to generate an RPG indicator host variable as a BOOLEAN. Because of this enhancement, an RPG program with an embedded SQL statement which references an RPG indicator host variable may have different behavior when the SQL program is recompiled on IBM i 7.5. An embedded INSERT, UPDATE, MERGE, SET, or VALUES INTO SQL statement may have different behavior when an RPG indicator host variable is assigned into a character variable or character column. Prior to IBM i 7.5, the value '0' or '1' would be assigned, but in IBM i 7.5, the value 'FALSE' or 'TRUE ' is assigned. This may cause an SQL0404 message (SQLCODE -404) or SQL0303 message (SQLCODE -303) when an RPG indicator host variable is assigned into a character variable or character column.

Existing programs which are not recompiled do not change behavior. If the previous behavior is required, the TGTRLS(*PRV | V7R3M0 | V7R4M0) parameter can be used on the Create SQL ILE RPG Object (CRTSQLRPGI) *CMD.

For additional information on the SQL BOOLEAN data type, refer to https://www.ibm.com/support/pages/
node/6575531.

*Regards*

*Vern Hamberg*

IBM Champion 2025 <cid:part1.nG2TUe9D.i4Em1NmZ@centurylink.net> CAAC (COMMON Americas Advisory Council) IBM Influencer 2023


On 5/2/2026 1:43 PM, Jon Paris wrote:
I understand all that Daniel but the underlying data type for an RPG indicator has always been char(1).

Perhaps more to the point:

1) if this was a coding error on my part, the pre-compiler should spit it out. Not accept it and screw up at run time.

2) This has been working since 2024

3) If I manually cast the indicator I no longer get an error but the value returned is not zero or 1. It is currently a “T” for the *On condition.

4) The table has been around for some time and a bunch of other stuff would have to change if I switch it to boolean. I’d rather avoid that.

Looks like I’m going to have to “manually” interpret the indicator and pass the resulting char field to the SQL.


Jon Paris


On May 2, 2026, at 14:27, Daniel Gross<daniel@xxxxxxxx> wrote:

Hi Jon,

if you use an indicator for the RESULT column, the natural SQL data type would be BOOLEAN. An indicator can only be *ON or *OFF - a Boolean column can only be TRUE (*ON) or FALSE (*OFF) - an embedded SQL is correctly casting/converting between those 2 data types.

HTH
Daniel


Am 02.05.2026 um 20:15 schrieb Jon Paris<jon.paris@xxxxxxxxxxxxxx>:

Apologies if this is a dup but my original was rejected (I think) and I can’t see anything for May in the archives.

I have a table defined as:

REGISTERTIME TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP,
WEBINARID DECIMAL(11, 0) NOT NULL DEFAULT 0 ,
RESULT CHAR(1) NOT NULL DEFAULT '0' ,
REGISTERDATA VARCHAR(1000) ALLOCATE(300) CCSID 37 NOT NULL

The SQL statement to insert the data is:

Insert into table ( webinarId, result, registerData )
values( :webinarId, :result, :request );

Where the columns are all defined as per the table definition - except that “result” in the RPG code is an indicator.

This code has been running for a couple of years but since our move to 7.6 has started to sometimes throw SQLCODE -404 against the “result" column claiming that its length of 4 exceeds the capacity of the column. But it isn’t 4 long it is 1. Running in debug, I can see that the temp variable for “result” created by the pre-processor is char(1).

Not sure where else to look.

I have googled for PTFs or reported errors but am not seeing anything.

Anyone got any ideas on where to look next?

I have a work around - if I face the cast of the indicator to char(1) it works. Guess there is a bug in the code generated by the pre-compiler.

Insert into partner400/sqlregtest ( result, webinarId, regData )
values( cast (:result as char(1)), :webinarId, :request );


Jon Paris

--
This is the RPG programming on IBM i (RPG400-L) mailing list
To post a message email:RPG400-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit:https://lists.midrange.com/mailman/listinfo/rpg400-l
or email:RPG400-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
athttps://archive.midrange.com/rpg400-l.

Please contactsupport@xxxxxxxxxxxxxxxxxxxx for any subscription related questions.

--
This is the RPG programming on IBM i (RPG400-L) mailing list
To post a message email:RPG400-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit:https://lists.midrange.com/mailman/listinfo/rpg400-l
or email:RPG400-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
athttps://archive.midrange.com/rpg400-l.

Please contactsupport@xxxxxxxxxxxxxxxxxxxx for any subscription related questions.


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2026 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.