With the speed IBM has been adding features, it's a good idea to get a recap once in a while.

If you've been following my recent articles, you probably noticed I've been bouncing back and forth between RPG programming and SQL programming. My last article spent a lot of time on SQL. This one will focus on RPG. Specifically, I'd like to discuss a couple of the more-beneficial new features introduced into RPG ILE over the past few releases.

Something Old and Something New

If OS releases were specified only as VxRyMz the last time you looked at the RPG manual, you’ll be happy to know that a lot of great new features have been added to the language. Many of these features have been around for a while, but if, like me, you didn't know about them, then they're new to you!

In fact, I'm going to start with an update on my recent timestamps article. By default, a timestamp is defined as CCYY-MM-DD.HH.MM.SS.mmmmmm, where that last "mmmmmm" section represents the microseconds of the timestamp. If you've done much work with timestamps, you'll know that, even though the default is six digits of precision as shown above, RPG populates the value to only three positions (representing milliseconds). Because of this, whenever you looked at the character representation, you'd see values ending in something like "12.32.45.667000", where the last three digits were always zero. I've written a lot of lines of RPG code trimming or padding those character values.

A feature introduced in version 7.2 allows you to specify the "precision" of the timestamp. Specifically, it allows you to specify the number of digits of precision for the seconds portion of the timestamp. There's no way to change the precision of the %timestamp BIF itself, but you can at least change the precision of the variable so that you don't get those extra zeros. Here's a little program that will demonstrate how the timestamp precision works.

      dcl-s ts timestamp inz(*sys);

     dcl-s ts3 timestamp(3) inz(*sys);

     dcl-s ts0 timestamp(0) inz(*sys);

     dsply ('TS : ' + %char(ts));

     dsply ('TS3: ' + %char(ts3));

     dsply ('TS0: ' + %char(ts0));

     *inlr = *on;

      return;  

Compile and run this program and you'll see the following:

DSPLY TS : 2018-07-09-20.22.32.810000

DSPLY TS3: 2018-07-09-20.22.32.810

DSPLY TS0: 2018-07-09-20.22.32    

Each line shows the character representation of the timestamp. The first is the default; you'll note that it shows six digits of precision in the seconds, which leads you to believe you're seeing microseconds but, as mentioned above, only the first three digits are actually populated. The extra zeros are meaningless. The more accurate version is TS3, which has explicitly defined three positions of decimal precision, and the character representation shows it. If you need milliseconds, this is the way to define your timestamp. The last version is the one I particularly like, using a zero for precision. The character version of this variant doesn't show any fractional seconds and instead is just a standard CCYYMMDDHHMMSS, albeit with slightly unusual punctuation.

Better Support for Long Names in Record-Level Access

As soon as you get a chance to use SQL's CREATE TABLE to define a database table, you are almost immediately going to want to use longer, more descriptive names. In fact, you'll want to be careful that you don't get fieldname-itis (inflammation of the field name) in which you end up with field names like BusinessUnitLevelAccountNumberingMethod. Not that there's anything wrong with that, but there's something to be said for conciseness even when not required.

But regardless of the verbosity of your field names, if they get longer than 10 characters, then you're going to run into a problem; RPG won't like them. Now, if all of your access is via SQL statements, it's not a problem. The length of your field names is not an issue, because you'll be defining the variables in your program name to receive the values from your SQL SELECT statement and you don't have any limitations. But if you want to access your SQL-defined table via a traditional file specification (whether it's a fixed-format F-spec or a free-format DCL-F), then you have an issue. Native file specification by default uses only the short version of the field name.

Now, you may be saying to yourself that you didn't specify any short field names (this, by the way, is done using the FOR clause in DB2). Well, fear not! DB2 makes up its own short field names for you by combining the first five characters of the long field name with a five-digit numeric value to retain uniqueness. For example, the first field above would be BUSIN00001. Another field named BusinessUnit would then be BUSIN00002 and BusingCompany would be BUSIN00003. Without any additional intervention, your RPG program would be forced to use those even-more-cryptic-than-usual field names.

The latest version of the compiler allows you to specify the ALIAS keyword on the file specification to tell it to ignore the short names and use all long names. This again isn't exactly new; the ALIAS keyword was available, but you could use it only if you also specified QUALIFIED on the same file specification. This in turn required you to do all your I/O operations using data structures. That's not necessarily a bad thing, but if all you want to do is CHAIN to a file and use the contents of a field, a data structure can feel like overkill. Anyway, let's take a look at what I might do. Let's assume that the file is simple and has only two fields: BusinessUnit and BusinessUnitLevel. You want to chain to this file to get the level of the business unit.

In one SQL statement, you create the table; in a second, you create an index over the table.

exec sql create table MYLIB/BUSUNITS (                

BusinessUnit char(10) not null with default,          

BusinessUnitLevel decimal(3,0) not null with default);

exec sql create index MYLIB/BUSUNITSI1                

on MYLIB/BUSUNITS (BusinessUnit);                    

Now you effectively have a physical file and a logical file: BUSUNITS and BUSUNITSI1. Please note that you haven't specified any short names, so the default IBM i behavior when looking at this file is to use the short field names BUSIN00001 and BUSIN00002. Not too long ago, that would have been the only way RPG could access those fields, but now it's very easy to use the long names. Behold:

ctl-opt actgrp(*new) option(*srcstmt:*nodebugio);

dcl-f BUSUNITSI1 alias keyed;                    

dcl-pi *n;                                      

iUnit like(BusinessUnit);                      

end-pi;                                          

chain (iUnit) BUSUNITSI1;                        

dsply %char(BusinessUnitLevel);                  

*inlr = *on;                                    

return;                                          

As you can see, just adding the ALIAS keyword to the BUSUNITSI1 specification means that you can use the long field name within your program. I define my input parameter as being LIKE the key field from the file (BusinessUnit), and then I work with the data field (BusinessUnitLevel). That's all it takes!

Two for the Price of One

Hopefully either or both of these two unrelated but very nifty compiler features can help you address other business issues (since that's why we're here, right?). Have fun with them both!