Proper naming is often overlooked, costing business countless hours that programmers could save if their stuff were labeled in a logical, practical fashion. Here are some tips on how to name your physical and logical files.

The previous two articles of this series (1 and 2) discussed prefixes and naming conventions for variables. This one will discuss files, and the next one will be about module and service-program naming conventions. However, unless you’re building an application from scratch, you already have your file structure in place, hopefully with some sort of logic behind it. Keep in mind, therefore, that I’m not suggesting that you rename all your files—just consider the following tips if, and only if, you’re adding a whole new module/business process to your application that requires new files. You can, however, plan the “makeover” of the database and execute it in phases. Naturally, this is hard to sell to management because there’s no obvious monetary gain in this process.

Having said that, here’s what I usually use:

For example, I’d use PFITMMST for an Item Master physical file. I also use a naming convention that allows an easy visual connection between a physical file and its logical files. So, this is my rule for logical files:

For example, I’d use LFITMMST01 for the logical file, with the most commonly used key for the item master physical file. From here, you can get creative and use, for instance, JF for join files. Just make sure you are consistent and coherent in the naming conventions you use.

Using Prefixes as a Workaround for Duplicated Field Names in Multiple Files

You should also be careful with the names of the fields inside your files. There’s a longstanding tradition, dating back to S/36, of keeping the field names six characters and using the same name for the same field in different files. While there’s nothing wrong with this, it can lead to some annoying problems. For example, when I started my first real job as a programmer, I wrote a program that accidentally changed the customer number in about half the records of a file. Why? Well, nobody told me that the customer number field had the same name everywhere in the database. I wrote a simple program that should have updated another field in the records of the file, but it left the wrong customer name in the CUSTID field as the result of a READ operation over another file. Since I didn’t use file prefixes (rookie mistake) or run the program in a small, controlled test set of data (another rookie mistake), the impact was considerable. (There was data redundancy and backups, so this didn’t get me fired!)

The point I’m trying to make here is that you should be able to identify the file to which the field belongs. There are a couple of ways to do this, but for now, let’s stick with file prefixes. Even if you already use them, keep reading; you might learn something new!

The PREFIX keyword is used to partially rename the fields in an externally described file by adding the specified prefix to each of them. This F-Spec keyword has two parameters: the prefix that you want to use, and the number of characters to replace. The first parameter is mandatory, but it can be an empty string, as you’ll see in the examples. The number of characters to replace is optional, and most people who already use the PREFIX keyword probably don’t even know that it exists!

Let’s start with the simplest and most common use of the keyword. Imagine that you have two files, named PFAAA and PFBBB. Both files contain the same the customer ID field, CUSTID. You can distinguish them by prefixing the CUSTID (and all the fields of both files) this way:

DCL-F PFAAA USAGE(*UPDATE : *DELETE)

DISK(*EXT)

KEYED

PREFIX(A_);

DCL-F PFBBB USAGE(*UPDATE : *DELETE)

DISK(*EXT)

KEYED

PREFIX(B_);

Note that the compiler will no longer recognize the CUSTID field from files PFAAA and PFBBB because they are now called A_CUSTID and B_CUSTID, respectively.

What you’ve read so far about the PREFIX keyword might not be new for you, dear reader, but have you ever used the “number of characters to replace” parameter? Here’s how it works: You specify the prefix to use in the first parameter, and an integer between zero and nine in the second. Specifying zero won’t get you anywhere, though, because replacing zero characters has the same effect as not specifying the parameter at all—nothing is replaced. Any value other than zero will “eat” the first n characters of the name of the field and, if you specify a prefix other than an empty string (‘’), put that prefix in its place.

For example, suppose file PFCCC has a bunch of fields that start with CCC and you want to replace those three characters with a C_ prefix (for whatever reason, it really doesn’t matter). Here’s how you’d do it:

DCL-F PFCCC USAGE(*UPDATE : *DELETE)

DISK(*EXT)

KEYED

PREFIX(C_ : 3);

This means that a field named CCCAMT would now be known as C_AMT. You might argue that the fields already have a prefix (CCC), so why bother replacing it? That’s true, but the second parameter can also be used to remove the CCC, like this:

DCL-F PFCCC USAGE(*UPDATE : *DELETE)

DISK(*EXT)

KEYED

PREFIX(‘’ : 3);

Here, the CCCAMT field would become AMT. Note that I specified an empty string (‘’) in the first parameter; I didn’t omit the parameter. Although an empty string is, well, nothing, it’s a valid string, which makes it a valid value for the first parameter.

There are a couple rules that you need to be aware of:

• The total length of the name after applying the prefix must not exceed the maximum length of an RPG field name.
• The number of characters in the name to be prefixed must not be less than or equal to the value represented by the “number of characters to replace” parameter. This means that after applying the prefix, the resulting name must not be the same as the prefix string.

If you go to the ILE RPG Language Manual, you’ll find a few more rules. I usually don’t use the “number of characters to replace” parameter, but there have been occasions in which it was useful to de-clutter the code, since all the fields in most files started with prefixes derived from the name of the file, in some cases with four characters. I used the second approach mentioned here to make the code more readable, replacing those in-name prefixes with a shorter prefix.

The next TechTip will discuss the final piece in this naming conventions tour: modules and service programs. Even though we’re limited to 10 characters, that doesn’t mean that the names chosen have to be undecipherable! Meanwhile, feel free to share with your fellow readers your own naming conventions; use the Comments sections below or the usual LinkedIn groups.