After the blog “Why You Should be Using Expert Cache” was published, I was asked a question via Twitter:
I forwarded the inquiry to the development team, but this tweet prompted me to write this blog about IBM i configuration defaults.
The IBM i development team recognizes that configuration customizations are very important and, as most readers know, nearly every aspect of the OS can be controlled by some sort of configuration parameter.
Selecting default settings for system configuration controls is not an easy task. IBM i environments range from the very small to the very large. A setting for an environment with five users may not be appropriate for an environment with 5,000 users. Most of the defaults chosen are safe—they work for everyone, although they may not be optimal for some environments.
Do they always get it right? Most of the time they do. And if the selected values aren’t quite right for your environment, you can change them. We also need to remember things change; perhaps what was a good choice in 1995 might not be a good choice today.
Changing the default for any configuration value is generally done with a lot of consideration and is very rarely done via a PTF. If a configuration setting is changed, it can lead to a change in behavior, and the IBM i development team tries hard to not change behavior. If something is changed, it tends to be done on a release boundary and the change is documented in the Memo to users (MTU). As an aside, there’s a common misconception that the MTU describes new things in a release; the MTU is not intended to describe new functions. Its purpose is to summarize the things that have changed in behavior from the prior release (i.e., “A” used to behave like this, but “A” now does this.).
There have also been times when some attribute was not configurable but should have been. These can be difficult to deal with, particularly if the issue needs to be addressed in a shipped (GA’d) release. You may have seen changes where the PTF cover letter includes instructions to create a data area or an environment variable and set it to some specific value. This approach provides a way to add configuration parameters when it’s not possible to extend the user interface. However, this approach also requires that you know about the change and how to take advantage of it. This blog is a common location to describe these types of updates.
Overall, I think the ability to configure and tune IBM i for the variety of environments in which it’s used is pretty impressive. Of course, your challenge is to know about the configuration options that apply to your environment.
This blog post was originally published on IBMSystemsMag.com and is reproduced here by permission of IBM Systems Media.