Importing and exporting pubsets is much more complicated for SM pubsets than for SF pubsets because SM pubsets contain specific metadata.
If the IMPORT-PUBSET command is specified for an SM pubset, the IMPORT task calls the HSMS. HSMS checks the names of the SM pubset’s control and request file, reads the control file in storage tables and reactivates the requests of the request file. The general catalog facility is opened and the pubset’s saturation level is checked. A check is run to remove all SF definitions of the pubset from the HSMS tables. SF definitions can occur if the SM pubset was converted under the same catalog ID or if the SM pubset is imported to another host. (Removal of the SF definitions is not final because this is not done in the control file but in the common memory pool.)
When the startup processing is complete, the SM pubset is available to HSMS. The IMPORT task waits for up to about 2 minutes for completion of the startup processing; then it hands back control.
If an error occurs during the HSMS startup processing, it is aborted even though importing of the pubset is continued. This results in an SM pubset which the DMS can access but which is not “HSMS-started”. HSMS recognizes any such situation and automatically triggers a new startup as soon as the next action is carried out in the environment. For example, when the SHOW-SM-PUBSET-PARAMETERS statement is issued, HSMS attempts to restart the environment. This gives the HSMS administrator the opportunity of remedying a startup processing problem without having to fully export/import the SM pubset. The task that requests the environment start waits again for up to about 2 minutes for completion of the startup processing. The HSMS statement requesting the startup fails if an error or a timeout occurs (although in this case the startup is continued asynchronously).
When the subsystem is created, this HSMS import processing is also automatically called by the HSMS main task for each currently accessible SM pubset under HSMS control.
With the EXPORT-PUBSET command for an SM pubset the entire HSMS stop processing is implicitly carried out for an SM environment. The stop processing, as its name suggests, cancels all requests with status ACCEPTED. In addition, it waits until all requests that have been started are completed. A message is output to the operator terminal for each HSMS server task currently working in the environment. When the synchronization point is reached, the EXPORT task deletes the archive definitions of the SM environment from the memory and hands back control.
Requests with status ACCEPTED that were cancelled by the export processing, are not deleted. They remain in the request file and are reactivated the next time the SM pubset is imported.
This does not apply to cancelled Concurrent Copy requests which do not use SHC-OSD mirroring functions and whose session is deinitialized by the EXPORT task. Such Concurrent Copy requests are given the CANCELLED status the next time the SM pubset is imported because they cannot be restarted. No processing occurs and no report is available. If a request like this is prematurely deinitialized by an export, the EXPORT task sends a message to the operator terminal.