Naming Conventions › Constraints on Naming Conventions › Object-action Naming

Object-action Naming

Under an object-action approach to naming, in line with an object-oriented approach to design, distinguish between:

• those items that implement a process; for example programs or commands. (Actions)
• those items that are operated upon by a process; for example, database files or data areas. (Objects)

This distinction can be seen in OS/400. Things upon which you operate (QPRINT, QBATCH, QINTER), are named differently from the things you use to perform the operation, which are named after the operation itself; for instance DSP (DSPSBS, DSPOUTQ), or CRT (CRTSBSD, CRTOUTQ).

Name all objects needed to implement a process after the process (programs and device files); and all objects that are operated on by processes (subjects of actions) by what they represent.

This allows you to identify all the objects needed to run a given command or a HLL program, apart from application-wide objects, which is assumed to be generally needed.

Why not name programs and device files the same name as the command that invokes them, since OS/400 object names only need to be unique within object type? For example:

This is unviable, as the relationship between the object types is often not one-to-one. A single command may cause many programs to be invoked or a single program may be called by several commands. It is, however, a useful approach to take when naming work management objects, which are related on a one-to-one basis. For example, job description QBATCH may submit jobs to job queue QBATCH that attaches to subsystem QBATCH that has a default class of QBATCH. In such a case, using common names for related objects of different types indicates any horizontal linkage across the OS/400 entity hierarchy.