When tuning OAM, there are a finite number of connections to DB2 from a batch environment that you need to consider. A number of functions, which are initiated by operator commands or automatically (for example, storage management cycle), might each result in multiple connections to DB2. OAM also establishes connections to process application requests. All of these connections established by OAM are in addition to the other necessary batch connections on your system. The total of all these connections at any given point in time must not exceed the DB2 limit because exceeding the limit causes OAM processing to fail.
The amount of concurrent function requests made of OAM control the tuning of OAM connections to DB2. Tuning OAM can involve limiting the number of concurrent functions requested automatically or by operator commands. A storage management cycle, for example, might establish three, four, or more connections to DB2 that persist for a good portion of the processing for each Object storage group. When deriving a value for MAXS, consider the number of connections, because MAXS controls the number of storage groups that the storage management cycle processes concurrently. While other calculations might seem to accommodate a larger number for MAXS, you must remember the DB2 limitation and adjust MAXS accordingly. Each installation is unique and must be tuned independently based upon actual experience; however, as a general guideline, as MAXS is increased above 10, the effectiveness of concurrency is diminished and might severely constrain processing in OAM or cause OAM processing to be unsuccessful. In an OAMplex, contention can increase with DB2 data sharing. When working with this type of environment, consider all the OAMs within the OAMplex when determining the storage group processing cycles and MAXS values for each instance of OAM.