Why Names Matter on IBM i
IBM i consultant Dawn May discusses approaches that streamline the search for information
The way we refer to friends and locations illustrates the importance of being specific in the names we use. Our last name is useful, as it can allow us to group a set of people: “Let’s invite the Mays over for dinner” extends the invitation to a group. But there are many Mays in the world, and we might need to narrow it down to the Mays who live on April Street instead of the Mays who live on June Street. And perhaps we want Dawn May on April Street and not Evening May, who lives a few houses away.
Likewise, the names of things on your IBM i are extremely important. Some shops do a good job with naming, while others struggle. IBM itself has a naming convention for system-supplied objects. Names begin with Q and are generally followed by a component ID and then a cryptic name suffix. However, IBM names are not always the best, particularly for server jobs that do work on behalf of a client. With a little foresight, we can organize naming to make it easier to find information at a later date.
Jobs and Their ‘Houses’
Let’s consider prestart jobs, one of my favorite topics. First, the shipped configuration puts most of these jobs in QUSRWRK (I think of them all living in the same house). However, IBM gives us the ability to segregate these jobs into different subsystems (different houses). But every family in that house has the same surname.
This means that when we invite QZDASOINIT to dinner, everyone comes to the party. If we want to find the troublemaker in the family of QZDASOINIT, it becomes difficult because we now have to find their first name—aka, the current user of that job. When we ask the surname of who is the problem child, we get QZDASOINIT. If we go to HOUSE1, DAWN, AMY, SAM or LIZ may answer the door, but we may not be at the right house because it may be MATTHEW in HOUSE2 who is the problem. But the only information we were given was that it was in the family of QZDASOINIT.
We can fix all of this by giving systematic names to subsystems, jobs and users. By appropriately separating work when setting up a system, we can streamline investigation later.
Think about all the work on your IBM i as an extended family. Consider each unique application a different family and put them in separate houses (subsystems). Subsystem names should reflect that family’s house. Each family should have a different surname (job name); we do not want everyone to have the surname of QZDASOINIT. The surname should also reflect the application. The goal should be to specify the job name on the prestart job entry (ADD/CHGPJE commands, JOB parameter).
Architecting Generic Job Names
Naming is a very important decision. The job names (surnames) should be unique in the first six characters. This is because of the IBM i tools that allow us to use generic job names, particularly in the Performance Data Investigator. PDI always uses the first six characters of the name for grouping jobs by generic job name. If generic job names are architected correctly, you will easily be able to group the family’s work together.
A good generic job name has the unique portion at the beginning of the name. A bad generic job name has the unique portion at the end of the name. Consider the QSQSRVR family. Assume we have three different families: A1QSQSRVR, B2QSQSRVR and C3QSQSRVR. When we use generic names, this easily shows us three families: A1QSQS*, B2QSQS* and C3QSQS*. But if we were to use surnames of QSQSRVRA1, QSQSRVRB2 and QSQSRVRC3, generic names would give us one family of QSQSRV*.
First names are also important when stipulating user profile names. For individual user profiles, many shops have naming conventions—DMAY or MAYD is a common example. Again, consider generic names as above when defining the naming convention. While the PDI does not use generic user names, tools like iDoctor do, so the same considerations described above should also apply to user names. I strongly recommend devising a naming strategy that makes the first six characters unique.
When you architect good strategies for organizing work into subsystems and naming jobs and user profiles, you can quite easily understand the system resources used by any application. It also significantly eases troubleshooting.