At POWERUp18 this May, someone asked me “When will RPG’s native file access support long names from databases and display files?” The answer is: it already does and has for quite some time! Originally it required reading into data structures, but that’s not even true anymore. Today, RPG’s native file access fully supports long names!
Since having that conversation, I’ve been asking around. It seems that not many RPGers know about this very useful feature. So in today’s post, I’ll show you how it works.
What I Found Out When Asking Around
I didn’t do any sort of official survey, and these statistics weren’t achieved scientifically, but…while I was informally asking around, here’s what I discovered:
- “Everyone” knows you can create column (field) names longer than 10 characters using SQL
- “Everyone” knows you can read, insert, update and delete using long field names in SQL
- About half of the people know that DDS also supports long field names
- About 25% thought RPG could use long names if you use data structures for I/O
- Only a few people (maybe 5%) knew RPG supports long names without data structures
We can do it with or without data structures! The data structure support has been around for a long time, and perhaps that’s why more people are familiar with it. (But, it can be awkward to code.)
The ability to use long names without data structures was added in 2014. If you have the latest PTFs for RPG on IBM i 7.1 or 7.2, then you have this support already. It was also included in the RPG compiler that was shipped with IBM i 7.3 in 2016. If you’re running 7.3, PTFs aren’t even needed.
Defining Tables with Long Names in SQL
Defining a field name longer than 10 characters is very natural in SQL. You simply define your table with a statement like this:
What may not be obvious, however, is that when a field is longer than 10 characters, there are actually two names assigned to it. The regular “column name” and what SQL refers to as the “system name”, which is limited to 10 characters for compatibility with older tools like CPYF, OPM languages or CL programs. In the above example, the system will generate names like CUSTO00001 for CUSTOMER_NUMBER and COMPA00001 for COMPANY_NAME.
Since there are still a lot of places where you might want to use the shorter system names, I recommend explicitly naming them. That way your short names can be meaningful. For example:
When you are working on modernizing your databases, this dual-name approach is really handy because it lets you keep the old, short (and often ugly) names that you’ve always used, keeping the files compatible with older programs. New programs can use the longer names and be more readable. Eventually, you can rewrite all the programs to use the long names, so this is a great tool for modernizing!
Long Names in DDS (Including Displays and Printers!)
DDS also supports long names using the ALIAS keyword. The name “alias” makes sense if you think about it, since any time you have a field longer than 10 characters, there are two names and either can be used. In other words, they are aliases for each other.
The DDS equivalent would be coded like this:
Mind you, I don’t recommend defining your new physical files using DDS, but for existing files, it may be easier to simply add the ALIAS keyword than to re-do the file using SQL.
Another reason why it’s important to know about the ALIAS keyword in DDS is because it also supports externally defined display, printer and even ICF files. Since all of these types of files support long names and have a great mechanism for backward compatibility with programs that must use short names, there’s no reason not to take advantage of this!
Long Names in RPG Programs
Like DDS, RPG uses the term “alias” when referring to long names. Starting with IBM i 7.1, RPG was able to use this long name support in qualified external data structures. This original support also required you to qualify the record format names (by using the QUALIFIED keyword on the F-spec) because without this keyword, RPG generates input specs. At the time 7.1 was released, I-specs did not support long names.
This support that shipped with 7.1 could be somewhat awkward. For example, the code to update the last paid date for customer 1000 would look like this:
I found this awkward because you had to use separate data structures for input and output (though, a PTF was released later that relaxed that rule) and you had to qualify both the field and record format names. I don’t know if everyone agrees, but I found that cumbersome!
The 2014 update added full support for long names, without any need to use data structures at all! So, if you’re up-to-date on PTFs and are running IBM I 7.1 or newer (which you really should be), you can do this instead:
Naturally, the alias keyword works in free format code as well. Here’s an example:
Don’t forget that alias support extends to display files and printer files, too! There’s no reason to use short cryptic field names anymore. Take advantage of the long ones. You’ll love it!