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.
Bob Cozzi is a programmer/consultant, writer/author, and software developer. His popular RPG xTools add-on subprocedure library for RPG IV is fast becoming a standard with RPG developers. His book The Modern RPG Language has been the most widely used RPG programming book for more than a decade. He, along with others, speaks at and produces the highly popular RPG World conference for RPG programmers.
MC Press books written by Robert Cozzi available now on the MC Press Bookstore.
 |
||
 |
|
RPG TnT Get this jam-packed resource of quick, easy-to-implement RPG tips! List Price $65.00 Now On Sale
|
|
||
 |
|
The Modern RPG IV Language Cozzi on everything RPG! What more could you want? List Price $99.95
Now On Sale
|
More than ever, there is a demand for IT to deliver innovation. Your IBM i has been an essential part of your business operations for years. However, your organization may struggle to maintain the current system and implement new projects. The thousands of customers we've worked with and surveyed state that expectations regarding the digital footprint and vision of the company are not aligned with the current IT environment.
TRY the one package that solves all your document design and printing challenges on all your platforms. Produce bar code labels, electronic forms, ad hoc reports, and RFID tags – without programming! MarkMagic is the only document design and print solution that combines report writing, WYSIWYG label and forms design, and conditional printing in one integrated product. Make sure your data survives when catastrophe hits. Request your trial now! Request Now.
Forms of ransomware has been around for over 30 years, and with more and more organizations suffering attacks each year, it continues to endure. What has made ransomware such a durable threat and what is the best way to combat it? In order to prevent ransomware, organizations must first understand how it works.
Disaster protection is vital to every business. Yet, it often consists of patched together procedures that are prone to error. From automatic backups to data encryption to media management, Robot automates the routine (yet often complex) tasks of iSeries backup and recovery, saving you time and money and making the process safer and more reliable. Automate your backups with the Robot Backup and Recovery Solution. Key features include:
Business users want new applications now. Market and regulatory pressures require faster application updates and delivery into production. Your IBM i developers may be approaching retirement, and you see no sure way to fill their positions with experienced developers. In addition, you may be caught between maintaining your existing applications and the uncertainty of moving to something new.
IT managers hoping to find new IBM i talent are discovering that the pool of experienced RPG programmers and operators or administrators with intimate knowledge of the operating system and the applications that run on it is small. This begs the question: How will you manage the platform that supports such a big part of your business? This guide offers strategies and software suggestions to help you plan IT staffing and resources and smooth the transition after your AS/400 talent retires. Read on to learn:
LATEST COMMENTS
MC Press Online