Midrange News for the IBM i Community


Posted by: Bob Cozzi
Rogue Programmer
Cozzi Productions, Inc.
Chicagoland
RPG IV Much Needed and Never Implemented Features
has no ratings.
Published: 03 Sep 2015
Revised: 09 Oct 2015 - 714 days ago
Last viewed on: 22 Sep 2017 (1807 views) 

Using IBM i? Need to create Excel, CSV, HTML, JSON, PDF, SPOOL reports? Learn more about the fastest and least expensive tool for the job: SQL iQuery.

RPG IV Much Needed and Never Implemented Features Published by: Bob Cozzi on 03 Sep 2015 view comments(4)

Return to midrangenews.com home page.
Sort Ascend | Descend

COMMENTS

(Sign in to Post a Comment)
Posted by: BrianR
Premium member *
Green Bay, WI
Comment on: RPG IV Much Needed and Never Implemented Features
Posted: 2 years 19 days 6 hours 49 minutes ago

For translating fields between different character sets, my suggestion would be to allow the CCSID keyword to be used on a character field definition.  It's currently allowed on graphic and UCS2 fields.  So character translation could be as easy as:

Dcl-s string char(30);

Dcl-s srtingascii char(30) ccsid(819);   (or ccsid(*ascii))

stringascii = string;

Posted by: BrianR
Premium member *
Green Bay, WI
Comment on: RPG IV Much Needed and Never Implemented Features
Posted: 1 years 11 months 17 days 6 hours 6 minutes ago

I just read an article that stated in release 7.2 the CCSID keyword can now be used on character fields in addition to graphic and UCS2 fields, so translating between EBCDIC and ASCII is supported without having to use iconv.  (see code example above)

Posted by: GFuste
Premium member *
Jacksonville, FL
Comment on: RPG IV Much Needed and Never Implemented Features
Posted: 1 years 11 months 16 days 13 hours 18 minutes ago

Great ideas and I know you've been pitching them for a long time.  It seems like IBM is spending its time making those kinds of functions available through SQL.

Posted by: bobcozzi
Site Admin ****
Chicagoland
Comment on: RPG IV Much Needed and Never Implemented Features
Posted: 1 years 11 months 15 days 6 hours 42 minutes ago

George,

From a performance stand point, I don't want to use SQL functions unless I'm using SQL itself. Not that SQL is slow, but the way Embedded SQL is designed is a lot of overhead due to excessively external calls.

But having said that, for one-off things, yes, using SQL is fine. Using some other language like embedded C runtime functions is also fine.