Your Browser is not longer supported

Please use Google Chrome, Mozilla Firefox or Microsoft Edge to view the page correctly
Loading...

{{viewport.spaceProperty.prod}}

Canceling pubset locks manually

&pagelevel(5)&pagelevel

The locks of the pubset management (pubset locks) are used in the shared pubset network to synchronize pubset reconfiguration requests with each other and with import and export jobs. Pubset locks are also used when a change to a pubset’s volume configuration is to be prevented, e.g. when creating a Snapset.

Types of pubset lock

Each pubset lock is recorded either on the pubset master or one of the pubset slaves in the form of a lock entry (see "Creating a shared pubset network"). The system on which the lock’s lock entry is recorded is referred to as the lock location. The lock entry includes information on the type and holder of the pubset lock (task ID and system ID).

The following types of pubset lock exist:

  • PUBSET-RECONFIGURATION
    Used to protect pubset reconfiguration requests from each other and from import and export jobs. This pubset lock can be set on the pubset master and on the pubset slave.

  • SHARED-EXCAT (held by export tasks)
    Prevents pubset reconfiguration requests, but permits parallel pubset locks. This pubset lock can be set on the pubset master and on the pubset slave.

  • SHARED-IMCAT (held by import tasks)
    Prevents pubset reconfiguration requests, but permits parallel pubset locks. This pubset lock can only be set on the pubset master.

  • SHARED-MASTER-EXCAT
    Prevents pubset reconfiguration requests, but permits parallel pubset locks of the type SHARED-EXCAT. This pubset lock can only be set on the pubset master.

The SHOW-PUBSET-LOCKS and REMOVE-PUBSET-LOCK commands (TSOS privilege) are provided to permit lock states to be diagnosed and to correct faulty lock states.

As pubset locks are internal pubset management locks, manual release should only be necessary in abnormal lock situations, e.g. after the failure of an MSCF connection in the shared pubset network. Abnormal lock situations exist, for instance, when the pubset management can determine via internal interfaces that the lock holder’s task is no longer active or is in the “pended indefinitely” state.

Examples of normal lock situations


Existing pubset lock

Requested pubset lock

PUBSET-RECON-FIGURATION

SHARED-IMCAT

SHARED-EXCAT

SHARED-MASTER-EXCAT

PUBSET-RECON-FIGURATION

Task waiting

Not permissible

Not permissible

Not permissible

SHARED-IMCAT

Not permissible

Permissible

Permissible

Not permissible

SHARED-EXCAT

Not permissible

Permissible

Permissible

Permissible

SHARED-MASTER-EXCAT

Not permissible

Task waiting

Permissible

Task waiting

Table 22: Combinations of pubset locks on the pubset master

In the examples below the shared pubset network consists of the pubset master with the SYSID “183” and two pubset slaves with the SYSIDs “184” and “185”.

  1. The following lock situation can, for example, occur when executing /MODIFY-PUBSET-PROCESSING. The command was entered on the pubset master or on the pubset slave (in the latter case the entire command is sent to the pubset master). Under the protection of a PUBSET-RECONFIGURATION lock on the pubset master, PUBSET-RECONFIGURATION locks are set on the pubset slaves, and after the processing which needs to be performed there has been completed, they are released again.

    /show-pubset-locks pubset-id=puba
    LOCK-TYPE      LOCK-LOCATION               LOCK-HOLDER-INFORMATION
                   HOSTNAME  SYSID  SHARER-    TID       SYSID  BS2000
                                    TYPE                        Version
    *PUBSET-RECONF D017ZE15  183    *MASTER    1000004F  183    V20.0
    *PUBSET-RECONF D017ZE16  184    *SLAVE     2000007F  184    V20.0
    *PUBSET-RECONF D017ZE17  185    *SLAVE     3000009A  185    V20.0

    2000007F is the TID of a MSCF server task on pubset slave “184”.
    3000009A is the TID of a MSCF server task on pubset slave “185”.

    Comment
    The PUBSET-RECONFIGURATION locks on the pubset slave do not need to be set at all times. Depending on the status of the processing operations, these locks need not yet be set or may already have been released again.

  2. The following lock situation can occur when executing /EXPORT-PUBSET which was entered on pubset slave “184”.

    /show-pubset-locks pubset-id=puba
    LOCK-TYPE      LOCK-LOCATION               LOCK-HOLDER-INFORMATION
                   HOSTNAME  SYSID  SHARER-    TID       SYSID  BS2000
                                    TYPE                        Version
    *SHARED-EXCAT  D017ZE16  184    *SLAVE     2000007E  184    V20.0
    *SHARED-EXCAT  D017ZE15  183    *MASTER    2000007F  184    V20.0

    2000007F is the TID of an export task on pubset slave “184”.

    Comment
    The SHARED-EXCAT locks on the pubset slave and pubset master do not have to be set simultaneously at all times. Depending on the status of the processing operations, the SHARED-EXCAT lock might only be set on one of the two systems.
    In this example no SHARED-EXCAT lock is set on pubset slave “185” because this system is not affected by the export job on pubset slave “184”.