General IBM i naming conventions principles applied

The adopted naming scheme is heavily influenced by more than 35 years’ experience developing commercial applications for the object based operating system known today as IBM i. Our choices are deliberate, in order to facilitate extracting maximum value from inherent operating system capabilities. Our chosen naming scheme adheres and implements the same constructs used within IBM i.

We need to formally acknowledge the significant contribution the Synon 2E (today known as CA 2E) approach made to formalize and document some of our fundamental deliberations.

The following considerations influenced the official naming scheme significantly:

It should be applicable to entities at all levels. IBM i entities include all IBM i object types/attributes, files, formats, fields, and members.
The naming of components should 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 other central reference.
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. We will distinguish between database files by both the file type (physical {table}/logical {view/index/LF/Join}) and the nature of the file’s contents; and distinguish between programs by their function.
Allow the names generated by the convention to lend them to generic manipulation. This means adopting names that give useful left to right generic names for manipulation by CL commands.
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, user spaces, users indexes, message queues), base their names on the significant entity that they represent; use the form ‘object’ or ‘adjective + object’. For example, Work with Active Jobs (WRKACTJOB), Date format system value (QDATFMT), communications subsystem (QCMN).
Encode as much useful information as possible within the names it generates about the role of the entity, and its relation to other entities.
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.
Use IBM i mnemonics wherever possible.
Follow an object-action system.
Be as compatible as possible with other standards, notably those inherent in the IBM i shipped system. For example, no object name should begin with the letter ‘Q’, which is reserved for IBM-supplied objects.

There are two separate interfaces in the IBM i architecture on which we focused:

The Control Language
The DDS and DDL specifications/language

It is possible that the “delivery channel” or “client” naming convention will differ from the database layer, due to language differences and the tooling being used.

As the tools and technologies for providing “delivery channels” are incorporated into intERPrise, those standards and conventions will be published for that environment as soon as it is adopted. The committee is desirous and committed that intERPrise should adopt all the mainstream and leading edge interface mechanisms that will provide value to the installed base.

The committee however does not foresee any display file (5250 DSPF) based solutions and strongly advises against it. However, the SMB installed base will dictate if they see any need for a DSPF based solution in an event driven paradigm.

All IBM i native components however have to conform to the published IBM i naming scheme.