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.
With IBM about to drop the 80-column punch card limit for RPG source statements, I thought I'd dig into my bag of things we've asked IBM to provide in RPG IV, but still haven't received nearly 20 years after RPG IV was originally announced. These are core features, not "I need to do this one custom thing and want something simple to allow it to happen".
[UPDATE:]
The new "really free format" requires that the literal *Free be the first thing in the source member. If it were my decision, I'd have implemented it as a new source member type ("SEU type") and called it a day. Something like SEU types
Seems like a more flexible choice to me. oh well
[/UPDATE]
Many of these features are available as subprocedure calls in my COZTOOLS product, but I think they should be in the core language itself.
Here's an article I wrote way back in early 2011 about how IBM could go "totally free format" with RPG IV. IBM has implemented much of what I had asked them to do, albeit their implementation is a bit less intuitive than I had expected. (http://www.midrangenews.com/view?id=1300)
Share your wish list in the comments below, but again, stick to core-widely-needed features, not something unique to your environment.
Thanks!
-Bob Cozzi
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;
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)
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.
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.