Naming Conventions › Planning a Naming Convention

Planning a Naming Convention

A naming convention for iSeries should do the following:

• be applicable to entities at all levels. OS/400 entities include all OS/400 object types, files, formats, fields, and members
• be rule-based. It should be possible to generate a new name or to analyze an old one by a rule, rather than by referring to a table or central log. The rules should be based on relevant categories of distinction; for instance, properties of the entities being named that are important in distinguishing them from other entities of the same type. You may want to distinguish between database files by both the file type (physical/logical) and the nature of the file’s contents (transient/permanent); you will want to distinguish between programs by their function.
• encode as much useful information as possible within the names it generates about the role of the entity, and its relation to other entities. Similarly, it should not contain irrelevant information.
• be easy to remember. Simplicity, consistency, and adherence to natural language principles will facilitate this.
• use the same name for an entity wherever it is used. For example, it should not be necessary to explicitly rename fields to overcome the limitations of a particular HLL, such as with RPG III.
• be as compatible as possible with other standards, notably those inherent in the OS/400 shipped system. For example, no object name should begin with the letter ‘Q’, which is reserved for IBM-supplied objects.

There are three separate interfaces in the OS/400 architecture with which you should be consistent:

• The Control Language
• The DDS Database description language
• The System displays and printouts

The CL command language interface in particular suggests certain naming practices; for example, use OS/400 mnemonics such as DSP for display wherever possible.

Follow an object-action system. Name objects that perform a function (commands and programs) according to the action they perform upon an object or entity; use the form ‘verb + object’. For objects that have actions performed upon them (as files, data areas, message queues), base their names on the significant entity that they represent; use the form ‘object’ or ‘adjective + object’. For example, Display Active Jobs (DSPACTJOB), Date format system value (QDATFMT), Batch subsystem (QBATCH).

Allow the names generated by the convention to lend themselves to generic manipulation. This means adopting names that give useful generic names for manipulation by CL commands. Also, ensure that names are tractable by the scan functions of source editor utilities such as SEU and object manipulation tools such as IBM’s Programming Development Manager (PDM). A generic name, indicated by an asterisk at the last position, encompasses the names of all entities, which begin with the same character string. For example, AB* implies all entities whose names begin with the letters AB.

Because of the limitations of the CL generic name, it is almost impossible to come up with a naming convention that completely satisfies this requirement. If you include indications of both an object’s type and its function in a name, one must be given precedence. Since sometimes you may want to manipulate objects by type, yet at other times by functional group, there inevitably can be a conflict. The floating generic name (*XXX*) capabilities of PDM can be used for generic manipulation on lower order parts of the name, provided you have adopted a convention that ensures related objects have at least some related component to their names.

The following example gives two different schemes for naming programs and files.