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 - 657 days ago
Last viewed on: 27 Jul 2017 (1682 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)

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

  • RPGLE
  • SQLRPGLE

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.

  1. %PGM - A built-in function to return "this" program's name.
  2. %JOBLOG - Write text (messages) to the joblog.
  3. %UPPER / %LOWER - Convert to upper or lower case.
  4. %SCANI - Scan and ignore case differences.
  5. %SNDMSG - Send Program Message
  6. %REGEX - Regular Expression Scan and Replace
  7. %TOASCII / %FROMASCII - Some way to use iconv() without all the complexities. It doesn't need to specifically be %ASCII, maybe %TRANSLATE or similar.
  8. %QCMDEXC - I'm tired of prototyping it everywhere I go. Just add it to the compiler please. %SYSTEM is an acceptible alternative.
  9. %FKEY - Returns the Fn key used to return control to the program from an EXFMT or READ to a DSPF.

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

 

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: 1 years 10 months 23 days 7 hours 25 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 9 months 21 days 6 hours 43 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 9 months 20 days 13 hours 54 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 9 months 19 days 7 hours 18 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.