Most OS/400 shops have implemented standards in an attempt at some level of consistency within the various applications. The use of naming conventions is one of the most commonly practiced standards in OS/400 shops. I see problems with one of the most popular naming conventions in use today. That convention is the two- and four-character field naming convention. Under this standard, the first two characters of a field name are used for association with the very database file in which the field is declared. The last four characters are used to identify the field. That is, the last four characters are used as the field name. I suppose this standard was logical at some point in history, but today I don't see the justification. After all, if a field is in the CUSTMAST file, why does the field need to begin with the letters CM? Doesn't the fact that it is in the CUSTMAST file make things clear enough? There is no reason to continue the antiquated two-character prefixing of field names. Ironically, the main reason I hear for using this is so that if you read one file and then another, the field's content is not overridden. Yet I see entire sections of RPG code dedicated to MOVE and MOVEL opcodes to copy the data from one input buffer to another. In addition, using only four positions to identify a data variable (i.e., field) is very restrictive. With very few exceptions, nothing can be accurately described in four characters. While the first two positions, which identify the database file, are used somewhat consistently, I find it rare that the last four positions are consistent. Take, for example, the Item Number field. I often find names like this: IMITMN
CMITM#
OEITEM All three of these fields follow the naming convention and actually refer to the same data element, the item number. The problem here is obvious; the four-position name component is different in each field name. The database supports longer names for fields. You can use up to 10 positions for field names, and you should in this day and age. Another problem occurs when using SQL. You have to remember not only the file prefix, but also the cryptic field name. If you're joining two files, and the name of the item number is IMITMN in one file but CMITM# in another file, you have numerous challenges and confusion. In addition, with SQL's correlation name capability, you can qualify any field to its file name or to a shorter, symbolic name, making the two-character prefix obsolete. Enforcing a two-character field name prefix and then not enforcing consistency for the rest of the field name is not promoting standards; it is a feeble attempt to control things, and it does not make them better. My recommendation is to set up shop standards for field names--but for the entire name, not for some silliness like prefixing field names. The field is in a file; that file owns the field; that's good enough. Referring to a field as CUSTMAST.ACCTNO or ORDDETL.ACCTNO is very clear. We don't need CUSTMAST.CMNBR or ORDDETL.ODCUST# (or even ORDDETL.ODNBR) in our systems; it can make impact analysis projects more difficult and in some cases virtually impossible. Of course, with RPG IV being the primary application development language on the AS/400 and iSeries today, we no longer need to concern ourselves with six-position field names. We can use the full 10 positions available with DDS (until we all start using SQL to declare our data). So consider revisiting any shop standards that include declaring fields with the XXYYYY format. It may be good for all your application projects. Bob Cozzi has been programming in RPG since 1978. Since then, he has written many articles and several books, including The Modern RPG Language --the most widely used RPG reference manual in the world. Bob is also a very popular speaker at industry events such as COMMON and RPG World and is the author of his own Web site, www.rpgiv.com, and of the RPG ToolKit, an add-on library for RPG IV programmers. | 
