SM pubsets can be exported and imported from system to system. Different HSMS versions could be in use on these systems. To ensure that the various HSMS control and request files are compatible, new compatibility features have been defined for the HSMS definitions on the SM pubsets: each archive or request within an SM pubset has a so-called version attribute. This attribute describes the HSMS version required for processing the archive or request. The following general rules apply:
When a definition is created for the first time, HSMS determines the oldest SMS version that can be processed by the definition.
Before a definition is used or modified, HSMS checks whether the requested HSMS version is sufficient for the definition.
When a definition is modified, HSMS redetermines the oldest HSMS version that can be processed by the definition.
If a definition is displayed with a SHOW statement, HSMS always tries to show as many correct operands as possible. If an operand is outside the permitted range, its value is represented by a question mark.
If an HSMS statement forbids an operand which affects an archive, the version attribute of the affected request is not decreased (for example, if an archive is assigned a shadow archive and the request was issued with SHADOW-COPY=*INHIBITED).
In the case of shared SM pubsets the slave sharers usually send their requests to the master sharer for processing.
When a slave sharer creates a request, it determines the functional HSMS version of the request by consulting the list of conditions described above.
When the master sharer receives the request, it first uses the functional HSMS version to check whether or not it can process the request. If the functional HSMS version of the request is higher than the HSMS version on the master sharer, the master sharer rejects the request.
This functional version mechanism enables sharers on which higher HSMS versions are running to transfer requests which do not contain any new HSMS functions to sharers with lower HSMS versions.