The management of requests which relate to shared pubsets is fairly complex. Requests issued to a slave sharer are usually sent to the master sharer for processing. For detailed information on “master” and “local” processing types, see section "Working with shared pubsets".
A request sent to the master sharer is copied by the master. A request issued by a user therefore is dealt with by two separate requests which share the same request identification. The original request generated on the slave host is called the primary copy of the request. The duplicate copy created by the master host is called the master copy of the request.
From the user’s point of view, request management functions can only be issued for the primary copy of a request, i.e. for the request that the user actually issued. Any existing master copy of a request is automatically managed by the request management functions.
A number of differences between SF and SM pubsets also affect the request management for shared pubsets:
In SF environments, the slave writes the primary copy of the request to its own HSMS global request file. The master writes the master copy of the request to its own HSMS global request file.
In SM environments, both the primary and the master copy of a request are written to the same request file of the SM pubset.
The special features of the request management for shared pubsets for the SHOW, DELETE and RESTART functions are described below.
Displaying requests on shared pubsets
With the SHOW function, master copies of requests can be recognized from the value YES in the output field FROM-REMOTE.
In SF environments, only the local copy can be displayed immediately, depending on whether the display is on the slave or the master host.
In SM environments, the primary and the master copy of the same request can be displayed at the same time if both of them meet the selection criteria for the request status. The master copy of the request is displayed immediately after the primary copy. The “HOST/TSN” field shows which request is running on which host.
Deleting requests from shared pubsets
Under the DELETE function, only the primary copies of requests can be selected. The associated master copies are implicitly deleted by HSMS. Deletion of the primary copy of a request can only be initiated after the associated master copy has been deleted.
A request cannot be deleted while its master copy has the STARTED status.
Requests which were defined in an SF environment can only be deleted from the host on which they were issued. The master host is called to enable implicit deletion of the master copy.
Requests which were defined in an SM environment can basically be deleted from every host which has imported the SM pubset. However, for as long as a request is locked by a host it can only be deleted by that host.
Restarting requests on shared pubsets
The RESTART function can only be issued for the primary copy of requests which have the status INTERRUPTED. However, the associated master copy is requested for this purpose because only the master copy contains the restart points that HSMS requires for a restart. If the master copy is not available or does not have the status INTERRUPTED, the restart will fail.
In SF environments, the request must be sent to the host that has stored the master copy of the request. The restart therefore always sends the request to the host that was the master sharer when the request was first processed, even if it is no longer the master sharer. If the host is no longer available, the restart will fail.
In SM environments, the restart can be issued from any host or sharer that has imported the SM pubset. If the system detects a master copy request, the primary copy of the request is modified using the checkpoint information of the master copy. The master copy is then removed from the request file. When the request has been processed, the master/slave configuration of the SM pubset is cancelled.
If the local host has slave access to the SM pubset, the request is sent for processing to the current master.