Sysplex considerations when using policies to manage pools, storage groups, and volumes
However, without proper planning, you could create an additional, unnecessary workload that causes duplicate processing.
Focusing on the SMPOLIxx and SMPOOLxx members with regard to sysplex configurations, assume that three interval definitions are defined to a policy. Two of the intervals are assigned a specific system ID, one to SYSA and the other to SYSB. The third interval has a default of all systems. If the policy member (SMPOLIxx) is shared between these systems, the intervals that are set for SYSA will run on SYSA but will not execute on SYSB. The intervals that are set for SYSB will run on SYSB but not SYSA. The third interval will run on both SYSA and SYSB.
The fact that the activity in the third interval runs on both SYSA and SYSB is of no consequence unless it is executing against the same volumes on both systems. This situation would happen if the SMPOOLxx member was shared as well. In this circumstance, if the activity was logging data, you would have duplicate data in your databases for these volumes; if automation was the activity, you would be executing the automation multiple times against these volumes.
One way to avoid the duplication of processing and still share PARMLIB members across systems is to assign specific system IDs in the intervals that you define. Another way is to allow the default of the intervals to be all systems, and to not share the SMPOOLxx member. With this method, you must also ensure that the pool definitions in the nonshared SMPOOLxx members are different. With proper planning, you can define and activate the members in a way that allows you to balance the workload across systems.
Comments
Log in or register to comment.