This solution hit the "bull's eye". Thank you very much! :)
Main Topics
Browse All TopicsWhen I run a store proc with a case statement it returns the result as EBCIDIC. When I run the same statement in iSeries Navigator the case statement returns the correct characters, not EBCIDIC.
Here is the SQL statement:
SELECT CASE
CL.CSTAT WHEN 'O' THEN 'Open'
WHEN 'R' THEN 'Reopen'
WHEN 'S' THEN 'Suspend'
WHEN 'C' THEN 'Complete'
WHEN 'I' THEN 'Incomplete'
ELSE 'UnKNOWN' END AS CSTAT
FROM SQBDCAPP.B99FL042 AS PR
INNER JOIN SQBDCAPP.B97FL01B AS CL
ON PR.RPOLST = CL.CPOLST
AND PR.RPOLNO = CL.CPOLNO
AND PR.RPOLCD = CL.CPOLCD
AND PR.RPOLOC = CL.CPOLOC
WHERE ( '7777777' IS NULL OR PR.RAGTNO = '7777777' )
AND ( '39' IS NULL OR PR.RPOLST = '39' )
AND ( '5500048310' IS NULL OR PR.RPOLNO = '5500048310' )
The above statement returns:
CSTAT
Open
Reopen
Complete
Here is the stored proc:
CREATE PROCEDURE SQBDCOBJ/LOSSRUN2B (
IN @AGENTID INTEGER ,
IN @STATE VARCHAR(2) ,
IN @POLNO VARCHAR(10) )
DYNAMIC RESULT SETS 1
LANGUAGE SQL
SPECIFIC SQBDCOBJ/LOSSRUN2B
NOT DETERMINISTIC
READS SQL DATA
BEGIN DECLARE C1 CURSOR FOR
SELECT CASE
CL.CSTAT WHEN 'O' THEN 'Open'
WHEN 'R' THEN 'Reopen'
WHEN 'S' THEN 'Suspend'
WHEN 'C' THEN 'Complete'
WHEN 'I' THEN 'Incomplete'
ELSE 'UnKNOWN' END AS CSTAT
FROM SQBDCAPP/B99FL042 AS PR
INNER JOIN SQBDCAPP/B97FL01B AS CL
ON PR.RPOLST = CL.CPOLST
AND PR.RPOLNO = CL.CPOLNO
AND PR.RPOLCD = CL.CPOLCD
AND PR.RPOLOC = CL.CPOLOC
WHERE PR.RAGTNO = @AGENTID
AND PR.RPOLST = @STATE
AND PR.RPOLNO = @POLNO ;
OPEN C1 ; SET RESULT SETS CURSOR C1 ;
END
When I run the above store proc: CALL SQBDCOBJ.LOSSRUN2B('777777
it returns:
CSTAT
D6978595
D98596978595
C39694979385A385
Does anyone know why the stored proc returns EBCIDIC instead of characters? I am new to iSeries SQL programming so I may be missing something obvious to an old timer. Any assistance is greatly appreciated.
Thanks,
Robert T
This Question has been solved and asker verified All Experts Exchange premium technology solutions are available to subscription members.
Experts Exchange has been collecting answers to technology questions since 1996…3 million and counting! If you have a question, chances are we already have your answer.
If you can't find the exact answer you're looking for, ask our exclusive community of 50,000 experts. You’ll get a personalized answer from a trusted professional.
Thousands of free tech tips, tricks, how-to’s and tutorials are available in our peer reviewed articles section. See for yourself how smart our experts are, no login required.
Access the answers to your technology questions today.
30-day free trial. Register in 60 seconds.
Members of the expert community talk about why the experience at Experts Exchange is different than what you will find anywhere else.

Try it out and discover for yourself.
30-day free trial. Register in 60 seconds.
Join the community of experts here and help other tech pros by answering question in your area of expertise. You can earn FREE access to all Experts Exchange's premium features and resources.
Business Accounts
Answer for Membership
by: Gary_The_IT_ProPosted on 2009-09-29 at 06:14:42ID: 25448589
iSeries stored procedures return EBCDIC by default. When you call a stored procedure through ODBC or JDBC, the driver typically translates the returned EBCDIC to ASCII for you on the fly, by default.
e.com/M_43 82324.html
Depending on your ODBC/JDBC settings, some fields may not be translated. My guess is that your system is set to default the CCSID to 65535, which means "no translation", and your ODBC/JDBC driver is set up to not translate binary fields to ASCII.
So, you can either declare or CAST your result column into a character column with a specific CCSID that the driver will properly translate for you, or you can configure your ODBC/JDBC driver to translate binary columns to ASCII. In ODBC it is in the data source configuration, and in JDBC, you need to add the
translate binary=true;
setting to your connection string, or otherwise set the property in your program.
In the example below, you can see that i chose CCSID 37. This is US EBCDIC (I just guessed from your time zone). This way, when you use this stored procedure locally on the AS/400, you will get EBCDIC results, and when you use it through ODBC/JDBC the driver will know that it is supposed to be automatically translated.
- Gary Patterson
Check out my EE profile: http://www.experts-exchang
Select allOpen in new window