Cluster Version

Terminology for Cluster Version

Cluster version. The cluster version identifies the communication level of the nodes in the cluster, the ability of a node to join the cluster and the ability of the cluster to support new function. It is composed of two parts, the version and the modification level. There are two representations of the cluster version, Current cluster version and Potential node version.

Current cluster version. The version at which the nodes in the cluster are actively communicating with each other. This value in conjunction with the Potential node version determines which nodes can join in the cluster. This value also determines the cluster's ability to use new functions supported by the node's potential node version. It is set when the cluster is created and can be changed by the Adjust Cluster Version (QcstAdjustClusterVersion) API.

Modification level. The modification level further identifies the version at which the nodes in the cluster communicate. It is updated when code changes that impact the communication between the cluster nodes are applied.

Potential node version. The version at which the node is capable of communicating with the other nodes in the cluster. This is the value associated with the cluster code installed on the node. It will be used to determine if the node can join a cluster. If communications have not yet been established with the node (status of New), then the potential node version will be reported as 0.

Version Restrictions

A cluster can be composed of cluster nodes that are at different cluster versions. There are, however, restrictions that are enforced:

1. New cluster version function is not available until all cluster nodes are at the new cluster version. The current cluster version must be equal to the new functions version. This implies the potential node version of all the nodes must be at the same version. For example, assume new function is provided in cluster version 2. The new function of cluster version 2 cannot be used if the current cluster version equals 1. The current cluster version cannot be adjusted to the new level until all cluster nodes are upgraded to version 2.
   
   
2. If N is the current cluster version, only nodes with potential node version of N and N+1 can join the cluster. N is defined when the cluster is created. This will either be the potential node version of the node that originated the create cluster, or the potential node version previous to the node that originated the create cluster request. For example if it is desired to have cluster nodes with a previous potential node version join the cluster, one of the following must be done:
   
   • Create the cluster on the node with the previous potential node version and add nodes with a higher potential node version to the cluster. The potential node version of the node being added must only be one version higher.
   • Create the cluster on the node with the higher potential node version specifying a target cluster version of -1. Then add the nodes with a lower potential node version to the cluster. The nodes being added must only be one version difference.
   
   
3. A cluster will run protocols at the lowest potential node version (N) only. This is defined when the cluster is first created. N can either be set to the potential node version running on the node that originated the create request or one potential node version previous to the originator's potential node version.

When adjusting the cluster version, the version is adjusted to be one level greater than the current cluster version. All nodes must have the same potential cluster version before the cluster version can be adjusted.

Relationship of cluster version to i5/OS VRMs

Cluster Version	i5/OS VRM
5	V5R4M0
4	V5R3M0
3	V5R2M0
2	V5R1M0

How to view the cluster versions

The current cluster version and the potential node version are retrieveable through the List Cluster Information and the Retrieve Cluster Information APIs.

Summary of API changes by cluster version

This documents the actual changes to the parameters on the APIs. The intent is to show which changes are allowed for the value of the current cluster version (CCV). The API changes for CCV 3 are only allowed on a V5R2M0 operating system or greater.

API changes allowed for CCV 5 (implies all of the below plus the following):

API changes allowed for CCV 4 (implies all of the below plus the following):

API changes allowed for CCV 3 (implies all of the below plus the following):

API changes allowed for CCV 2: