MIRROR (Mirror Disk)

The MIRROR (Mirror Disk) command controls the use of disk mirroring on the system. The command initiates an independent runner named MIRROR_CREATE. For a description of disk mirroring, refer to the System Operations Guide.

If you are using host-based mirroring, all MIRROR commands require the MIRRORING system option to be set by the OP (Options) command before the previous halt/load. You can use the MIRROR commands with the MIRRORING system option reset with Business Continuance Volume (BCV) disks.

On systems with the Mirrored Disk Pooling Facility (MDPF) installed, the MIRROR command is also used to set or reset the in-use spare attribute on labels for disks assigned to the spare disk pool. Use this command initially to establish the pool of in-use spare disks, and thereafter to manually add disks to or delete disks from that pool.

You cannot use this command on a pack that has an active DUMPDISK or HLDUMPDISK file. Mirror disks must have the same capacity as the disks for which they are copies.

Syntax

<global options>

<readdistribution option>

Explanation

MIRROR AUDIT PK <unit number>

Closes the pack specified by the unit number, leaving the remaining members of the set online. An audit table is established for the pack, so it can be synchronized with the other members of the set if it is later returned online.

This command is particularly useful when a member of a mirrored set is experiencing repeated, recoverable errors that degrade the I/O throughput to that set.

After auditing has been established with this command, I/O activity is not resumed to the auditing member until a RY PK <unit> command is executed. Refer to the RY (Ready) command.

 Caution

As with any offline mirror, a member that is being audited as a result of this command is released from the set and must be recreated if a halt/load occurs before it is brought back online.

One benefit of this command is that it enables you to create a new mirror without incurring the penalty of retrying I/Os to the offending mirror. That is, if a mirror experiences a number of recoverable errors, you can take it offline with the MIRROR AUDIT PK command, then create a replacement mirror with the MIRROR CREATE command. Since I/Os are not being issued to the offline mirror, the CREATE operation is not affected by I/O retries.

When the CREATE operation completes, you no longer need the offline mirror and can release it with the MIRROR RELEASE OFFLINE COPIES command.

If the CREATE operation fails to complete, you can still recover the offline mirror, because the MCP maintains an audit trail. Issuing an RY PK command brings the mirror back into the set. The RY PK command can also be used if the condition causing the recoverable errors is corrected without writing to the pack.

The pack designated by the unit number must be an online member of the set. If the command is issued to a member that is not online, the command is rejected and the following message is displayed:

MIRROR ACTION NOT DONE (NOT AN ONLINE MIRRORED DISK).

At least one other online member must be present. If the command is issued to the last online member of a set, the command is rejected and the following message is displayed:

MIRROR ACTION NOT DONE (LAST ONLINE MIRROR IN SET).

MIRROR AUDIT OFFLINE COPIES OF PK <unit number>

Brings the mirrored set online and audits its unavailable member or members.

MIRROR AUDIT OFFLINE COPIES OF ALL SETS

Provides a shorter version of the preceding command. The system is instructed to bring online all mirrored sets waiting to be brought online because of unavailable members.

MIRROR CERTIFY PK <unit number>

Verifies that the data contained in each online member of a mirrored set is identical. Every sector, except those that are identified as defective in the BADDISK file, is read and compared for each online member. Any data discrepancy is reported on the ODT. A report file is generated that logs any data discrepancies as well as the success of the certify process. When mirror certification completes, a certification timestamp is written on the disk label. The mirror certify timestamp for each certified member of the set is displayed as part of the OL (Display Label and Paths) command.

MIRROR CERTIFY generates a report for any data discrepancies encountered. If a data mismatch occurs on an unused sector, that sector is identified as AVAILABLE space. If the data mismatch occurs on an area used by the MCP, that sector is identified as IN USE BY MCP. Otherwise, the file name that contains the bad sector is reported. A block of consecutive mismatched sectors is reported as a single mismatch. The length of the mismatched block is reported.

A Mirror Certify license is required to run the mirror certification procedure.

MIRROR CREATE PK <unit number> FROM PK <unit number>

Creates a mirror copy of an existing pack. The source and destination packs must be identically formatted. For example, both packs could be 207 interlaced packs, or both could be 659 sequential packs. The existing pack can be a member of a mirrored set. Once the command is entered, copying begins. The new member automatically goes online when the copying is complete.

A disk added to the mirrored set is given the same time limit value as the current set members. The time limit of the set applies to the new member as it is being created. If an error prevents the disk from becoming an online member of the set, the original time limit is restored to the disk.

The command is rejected if four members already exist in the mirrored set. If the destination pack is in use or is already a member of a mirrored set, the command is also rejected.

MIRROR IGNORE PK <unit number>

If an attempt is made to bring a mirrored set online and one or more of its members are unavailable, this command causes the system to treat those members as if it had not yet encountered them. Do not confuse this command with the CLOSE (Close Pack) command. Unlike CLOSE, this command does not necessarily leave the set in a state in which all members are known to be identical, with their labels showing a closed state. Rather, it returns the packs to whatever state they were in before the attempt to bring them online. Members that have been ignored can be made ready later with the RY (Ready) command if you wish to bring up the set.

MIRROR IMPORT PK <unit number>

Once you have marked all of the family members to be imported, use the MIRROR IMPORT command to assign unique identification to the family to which the PK <unit number> belongs.

Importing a MIRROR SNAPSHOT COPY

When you are ready to separate the snapshot candidate from its original, any application software that is performing write operations to the mirrored sets representing the family must be quiesced by the user. The MIRROR IMPORT command is then entered to separate the snapshot candidate from its original and provide it with unique serial numbers and optional family name.

MIRROR IMPORT PK <unit number> NAME = <new family name>

When a MIRROR IMPORT command is issued, a check is first made to verify that the SAN Mirror Disk Manager key is present. If not, the operation is aborted and the following message is displayed:

SAN MIRROR DISK MANAGER KEY NOT INSTALLED

If the key is present, the following message is displayed. Its purpose is to verify that the user has quiesced all I/O to the family being imported:

PK<unit number> MIRROR IMPORT REQUESTED. OPERATOR IS 
RESPONSIBLE FOR QUIESCING I/O TO THE FAMILY TO ENSURE
DATA CONSISTENCY. REPLY 'OK' WHEN READY TO PROCEED.
'DS' TO ABORT.

If you reply OK, the following checks are made:

  • A check is made to verify that the base pack of the family is online, all online family members are mirrored, all members of each mirror set are online, and all online family members have a working I/O path. If not, the operation is aborted and the following message is displayed:

    PK <unit number> NOT ALL FAMILY MEMBERS PRESENT. 
    MIRROR IMPORT HAS BEEN ABORTED. I/O ACTIVITY CAN BE RESUMED.
  • A check is made to verify that all family members are present. If not, the operation is suspended and you have a choice of deleting missing members (OK response to the RSVP) or aborting the import (DS response to the RSVP). The following message is displayed:

    PK <unit number> ONE OR MORE FAMILY MEMBERS ABSENT.
    ENTER OK TO REMOVE ALL MISSING MEMBERS, DS TO QUIT.
    

    If you respond with a DS, the following message is displayed:

    PK <unit number> UNIT NOT AVAILABLE. 
    FAMILY INDEX <family index> MISSING. MIRROR IMPORT ABORTED.  
  • A check is made to verify that all family members have been marked. If not, the import operation is aborted and the following message is displayed:

    PK <unit number> NOT ALL FAMILY MEMBERS ARE MARKED. MIRROR IMPORT HAS
    BEEN ABORTED. I/O ACTIVITY CAN BE RESUMED.
  • A check is made for each mirror set that comprises the family to ensure that the snapshot copy and at least one other member of the mirror set is online. If not, the operation is aborted and the following message is displayed:

    PK <unit number> MIRROR SET MUST CONTAIN AT LEAST TWO ONLINE MEMBERS.
    MIRROR IMPORT HAS BEEN ABORTED. I/O ACTIVITY CAN BE RESUMED.

After the initial verification is complete, the members of the mirror set to be imported are placed offline by the MCP and are audited until successfully imported. The audit is maintained for the sake of error recovery. Once all the units are being audited, I/O activity can be resumed to the quiesced family. At this time the following message is displayed:

PK <unit number> MIRROR IMPORT COMMAND INITIATED.
I/O ACTIVITY CAN BE RESUMED.

Upon successful completion of the command, the following message is displayed:

FAMILY CONTAINING PK <unit number> SUCCESSFULLY IMPORTED

If an I/O error is encountered while trying to import a snapshot candidate, the failing mirror member is released from the mirror set. Family members that had been successfully updated prior to the I/O error are restored and are returned to the MARKED state. Audits are applied and these members are brought back online.

A mirror must be recreated to replace the failing disk. The new snapshot candidate must then be marked. If this situation occurs, the following message is displayed:

PK<unit number> IMPORT OPERATION FAILED. THE FAILING MEMBER
HAS BEEN RELEASED. RECREATE A MIRROR TO REPLACE THE FAILING
MIRROR, MIRROR MARK THE REPLACEMENT, AND REPEAT THE MIRROR
IMPORT PROCESS.

Importing a BCV Device

MIRROR IMPORT PK <unit number> NAME=<familyname>

This command checks the following:

  • A check is first made to verify that the HOST COMPONENT FOR EMC TIMEFINDER key is present. If not, the operation is aborted and the following message is displayed:

    HOST COMPONENT FOR EMC TIMEFINDER KEY NOT INSTALLED
  • A check is made to verify that all family members are present. If not, the operation is aborted and the following message is displayed:

    PK<unit number> UNIT NOT AVAILABLE. MIRROR IMPORT ABORTED.
  • A check is made to verify that all family members have been marked. If not, the operation is aborted and the following message is displayed:

    PK<unmarked unit number> UNIT NOT MARKED. MIRROR IMPORT OF
    PK<unit number> ABORTED.
  • A check is made to verify that all family members are present. If not, the operation is aborted and the following message is displayed which specifies the family index of the member which is not present:

    PK<unit number> UNIT NOT AVAILABLE. FAMILY INDEX
    <family index> MISSING. MIRROR IMPORT ABORTED.

Upon successful completion of the command, the following message is displayed:

FAMILY CONTAINING PK<unit number> SUCCESSFULLY IMPORTED

MIRROR IMPORT PK <unit number> RETAIN

This option of the MIRROR IMPORT command enables a user to bring a BCV device online while retaining the original family name and serial number. When the RETAIN option is used, the MIRROR MARK command does not have to be used because the serial number remains unchanged.

When the RETAIN option of the MIRROR IMPORT command is entered, the original copy of the BCV device should not be online. Use the CLOSE (Close Pack) and FREE (Free Resource) commands to place the original copy off line. This action avoids the generation of a duplicate serial number and allows the BCV device to be acquired using the ACQUIRE (Acquire Resource) command.

In this command, PK<unit number> specifies the member of the family to be retained. This command checks the following:

  • A check is first made to verify that the HOST COMPONENT FOR EMC TIMEFINDER key is present. If not, the operation is aborted and the following message is displayed:

    HOST COMPONENT FOR EMC TIMEFINDER KEY NOT INSTALLED
  • A check is made to verify that all family members are present. If not, the operation is aborted and the following message is displayed:

    PK <unit number> UNIT NOT AVAILABLE. MIRROR IMPORT ABORTED.
  • A check is made to verify that no family member has been marked. If so, the operation is aborted and the following message is displayed:

    PK <unit number> FAMILY MEMBER MARKED. MIRROR IMPORT ABORTED.

Upon successful completion of the command, the following message is displayed:

FAMILY CONTAINING PK <unit number> SUCCESSFULLY IMPORTED

If any I/O error occurs during the IMPORT operation of a BCV device, the operation is aborted and the following message is displayed:

PK<unit number> IMPORT OPERATION FAILED. SEE THE SYSTEM MESSAGE
MANUAL FOR RECOVERY INSTRUCTIONS.

To recover, you must first close and free all the BCV devices representing the family by using the CLOSE (Close Pack) and FREE (Free Resource) commands, including the BCV device that received the error. This action informs the MCP that these units are no longer accessible.

Using EMC TimeFinder, you can then establish a BCV mirror using the ESTABLISH command to replace the BCV which failed and RE-ESTABLISH the remaining BCV mirrors representing the family in order to apply any audits maintained by TimeFinder. Once the BCV units representing a family are RE-ESTABLISHED, the process of creating a snapshot can be repeated.

Marking a MIRROR SNAPSHOT COPY

MIRROR MARK + PK <unit number> SERIAL = <serial number>

Once a copy has been made for all members of a family, the MIRROR MARK command enables the user to specify the serial number to be used for the snapshot candidate when it is subsequently imported. This option also permits the operator to unmark a device and to display the MARK status of a family.

This command provides unique identification for a snapshot copy. This enables it to be imported from its original. This command checks the following:

  • The SAN Mirror Disk Manager key must be installed to mark a snapshot candidate.

  • The serial number must be unique. If it is not, the operation is aborted.

  • If a member that has been marked in the mirror set already exists , the operation is aborted.

  • If the unit specified to be marked is not available, the operation is aborted.

  • The unit must be eligible and a member of a mirrored set to be marked as a snapshot candidate.

MIRROR MARK − PK <unit number>

Unmarks a snapshot candidate. The unmarked unit is no longer a candidate to be imported.

MIRROR MARK PK <unit number>

The query form of the MIRROR MARK command displays the mark status of all the family members to which the PK <unit number> belongs. This status consists of the unit number, assigned serial number, family name, family index, and the pending serial numbers.

If the disk has been marked, the phrase MARKED is displayed. If the disk has not yet been marked, the phrase UNMARKED is displayed. This information is displayed in the following format for each family member:

 ------------------MARK STATUS-------------------
     100   [045678] #1 PERIPH MARKED (PENDING [12345])
     150   [023456] #2 PERIPH UNMARKED
 

If an I/O error is encountered while trying to update a snapshot candidate, the failing disk is released from the mirror set and you are notified. A mirror must be recreated to replace the failing disk. The snapshot candidate must then be marked. If this situation occurs, the following message is displayed:

PK<unit number> MARK OPERATION FAILED. THE FAILING MIRROR HAS
BEEN RELEASED. RECREATE A MIRROR TO REPLACE THE RELEASED MIRROR.
  

Marking a BCV Device

MIRROR MARK + PK <unit number> SERIAL = <serial number>

Once a BCV device has been acquired into the MCP environment, an option to the MIRROR MARK command enables you to specify the serial number to be used for the BCV when it is subsequently imported. This option also permits the operator to unmark a device and display the MARK status of a family.

This command provides unique identification for a BCV. This enables it to be imported from its original. This command checks the following:

  • The HOST COMPONENT FOR EMC TIMEFINDER key must be installed in order to mark a BCV. If it is not installed, the following message is displayed:

    HOST COMPONENT FOR EMC TIMEFINDER KEY NOT INSTALLED
  • A check is made to verify that the serial number is unique. If it isn't unique, the operation is aborted and the following message is displayed:

    PK <unit number> SERIAL NUMBER IS NOT UNIQUE.
    MIRROR MARK ABORTED.
  • The unit must be eligible to be marked. It must be a nonimported BCV. If it is not eligible, the operation is aborted and the following message is displayed:

    DISK IS NOT ELIGIBLE TO BE MARKED

Upon successful completion of the command, the following message is displayed:

PK <unit number> SUCCESSFULLY MARKED TO BE IMPORTED.

MIRROR MARK − PK <unit number>

This command unmarks a BCV device. The unmarked unit is no longer a candidate to be imported. Upon successful completion of the command, the following message is displayed:

PK <unit number> SUCCESSFULLY UNMARKED.

MIRROR MARK PK <unit number>

The query form of the MIRROR MARK command displays the mark status of all the family members to which the PK <unit number> belongs. This status consists of the unit number, assigned serial number, family name, family index, and the pending serial numbers.

If the BCV has been marked, the phrase MARKED is displayed. If the BCV has not yet been marked, the phase UNMARKED is displayed. This information is displayed in the following format for each family member:

-----------------MARK STATUS-----------------
    100   [045678] #1 PERIPH MARKED (PENDING [12345])
    150   [023456] #2 PERIPH UNMARKED

If any I/O error occurs during the MARK command, the operation is aborted and the user is notified that the process to mark the unit has failed. The following message is displayed:

PK <unit number> MARK OPERATION FAILED. SEE THE SYSTEM MESSAGES
MANUAL FOR RECOVERY INSTRUCTIONS.

To recover, the user must first CLOSE and FREE all the BCV devices representing the family, including the BCV that received the error. This informs the MCP that these units are no longer accessible.

Using EMC TimeFinder, you can ESTABLISH a BCV mirror to replace the BCV that failed and RE-ESTABLISH the remaining BCV mirrors representing the family in order to apply any audits maintained by EMC TimeFinder. This is necessary to ensure that the data on the family is coherent. Once the BCV units representing a family are RE-ESTABLISHED, the process of creating a snapshot can be repeated.

MIRROR OPTION DELAY

The query form of the MIRROR OPTION DELAY command reports the current setting of the global delay option.

MIRROR OPTION DELAY = <value>

Sets a delay value that can be used by any MIRROR CREATE initiated to apply an audit to a returning off-line member.

The value must be a number between 0 and 20. A nonzero value causes the MIRROR_CREATE independent runner to wait <value>*1/20ths of a second between data transfers when it is applying an audit to a returning off-line member. The value 0 clears a previously specified delay, so that audit transfers are executed without any induced delay.

This delay is not used when creating a new mirror (for example: MIRROR CREATE PK <x> FROM PK <y>).

The following example changes the global delay setting to 3/20ths second.

MIRROR OPTION DELAY 3

MIRROR OPTION QUICKAUDIT

Reports the current setting of the QUICKAUDIT global option.

MIRROR OPTION QUICKAUDIT ON

MIRROR OPTION QUICKAUDIT OFF

Set the global QUICKAUDIT option to the specified value and force the QUICKAUDIT error recovery option of all current mirrored sets to this value. The global QUICKAUDIT setting determines the initial QUICKAUDIT error recovery option setting for new mirrored sets.

MIRROR OPTION PARTIALSETS

MIRROR OPTION PSETS

Reports the current setting of the PARTIALSETS option: HLAUDIT or WAIT.

MIRROR OPTION PARTIALSETS HLAUDIT

MIRROR OPTION PSETS HLAUDIT

The HLAUDIT setting prevents the need for operator intervention if a partial set condition arises during halt/load initiation (for example, because a hardware failure caused a mirrored member to go offline). The HLAUDIT setting causes the system to force the logical volume online by performing one of the following actions:

  • Auditing offline members. If the system takes this action, it displays the following message during initialization. This message remains until acknowledged with an OK command, but does not delay system initialization:

    MIRRORED SET(S) PK <number,[number,[ ... ]]> WERE
    FORCED ONLINE BY AUDITING OFFLINE MEMBER(S).
    ACKNOWLEDGE WITH <mix#> OK
  • Releasing the missing members. The system takes this action if the outstanding write list (OWL) was lost for a RECOVERY=DISCARD mirrored set. The system displays the following message during initialization. This message remains until acknowledged with an OK command, but does not delay system initialization:

    MIRRORED SET(S) PK <number,[number,[ ... ]]> WERE
    FORCED ONLINE BY INVALIDATING ALL OTHER SET MEMBER(S)
    ACKNOWLEDGE WITH <mix#> OK

Note that the HLAUDIT setting forces the mirrored set online only if the set was previously online and the partial set condition arose during halt/load initialization. If a partial mirrored set condition arises for a set that was never completely online, or for which there was no MIT entry, or at any other time during system running, the system reverts to its default behavior of waiting for operator intervention. This restriction prevents the possibility of automatically bringing online an out-of-date copy of a mirrored volume. This restriction also prevents the system from breaking a mirrored set needlessly if one copy is erroneously made accessible to a system, or if the operator fails to enable access to all members of a mirrored set being brought online.

MIRROR OPTION PARTIALSETS WAIT

MIRROR OPTION PSETS WAIT

Specifies that the system should wait for operator intervention after a halt/load before making partial mirrored sets available for use. The system creates a PARTIALSETS waiting entry for any partial mirrored set. The data on these partial mirrored set volumes is not available for use by applications until either the missing members are brought online or the operator forces the volumes to come online by using the MIRROR AUDIT system commands.

WAIT is the default setting of PARTIALSETS.

MIRROR OPTION PK <unit number>

If no options are specified, the current recovery option settings for the specified mirrored set are displayed. QUICKAUDIT is included in the response only if enabled for the set. The setting of MANUALSYNC is included only if it is currently enabled.

MIRROR OPTION PK <unit number> DONTREAD = YES

MIRROR OPTION PK<unit number> DONTREAD = NO

Specify whether or not to exclude the specified disk unit from read operations distributed among mirrored disks. The DONTREAD feature is useful if you determine that read performance might improve when issuing mirrored reads to some members versus others.

For information about how the system distributes read operations among mirrored disks, refer to the description of the READDISTRIBUTION option later in this discussion.

The following example causes PK 1673 to be excluded from mirrored read distribution algorithms:

MIRROR OPTION PK 1673 DONTREAD = YES

MIRROR OPTION PK <unit number> QUICKAUDIT ON

MIRROR OPTION PK <unit number> QUICKAUDIT OFF

The QUICKAUDIT error recovery option for the specified mirrored set is changed to the specified value. If QUICKAUDIT is enabled for a mirrored set, improved real-time performance during I/O error recovery is achieved by temporarily decommitting a mirrored set member to audit, if possible, during recovery from certain slow transient errors.

MIRROR OPTION PK <unit number> READDISTRIBUTION . . .

MIRROR OPTION PK <unit number> RD . . .

Specify the method that the system uses to distribute read operations among mirrored disk units. The specific values for this option are described under their own headings later in this discussion. The following considerations apply to the READDISTRIBUTION option in general:

  • When the READDISTRIBUTION option is specified for a member of a mirrored set, it affects all members of the mirrored set.

  • The READDISTRIBUTION option takes effect on the next read from an online member of the mirrored set. The READDISTRIBUTION option is preserved across halt/loads.

  • The READDISTRIBUTION option can be used with any disk that is eligible for mirroring.

MIRROR OPTION PK <unit number> READDISTRIBUTION DEFAULT

MIRROR OPTION PK <unit number> RD DEFAULT

A READDISTRIBUTION value of DEFAULT restores the system default read distribution algorithm. The effect depends on whether the mirrored set is caching. Refer to the CACHE (Disk Cache) command for information on caching.

  • If the mirrored set is not caching, read operations are rotated evenly among the online members of the mirrored set.

  • If the mirrored set is caching, a static partitioning algorithm is used. This algorithm divides the address space of the mirrored set evenly among the online members of the set. The read operation is sent to the member whose portion of the address space includes the starting disk address of the read request.

    At fixed intervals of approximately four minutes, the system reassigns the mapping of the address space. Thus, if member 1 was previously assigned the low disk addresses, member 1 is now assigned the high disk addresses, and the reverse is done for member 2. In this way, the system refreshes the cache pages and ensures consistent access to all members of the set over time. This method ensures the cache contents are backed by a working device and also ensures that all devices of the mirrored set are exercised periodically.

For example, assume a mirrored set consisting of PK 45 and PK 55. The following command assigns the default read distribution algorithm to the mirrored set. If the mirrored set is caching, the static partitioning algorithm is used. If the mirrored set is not caching, reads are distributed evenly between PK 45 and PK 55.

MIRROR OPTION PK 45 READISTRIBUTION = DEFAULT

MIRROR OPTION PK <unit number> READDISTRIBUTION BYADDRESS

MIRROR OPTION PK <unit number> RD BA

A READDISTRIBUTION value of BYADDRESS causes the system to divide the disk address space evenly among the online members of the mirrored set. The effect is much like the default static partitioning used with cached mirrors, except that the address space is not rotated. Following are the effects of this value for various types of sets:

  • For a two member set, the first half of the address space is assigned to the first online mirror, and the second half of the address space is assigned to the second online mirror.

  • If a third member is added to the set at a later time, the address space is automatically divided into thirds.

  • If a member is lost or removed, the address space is automatically divided among the remaining members equally.

Depending on the application environment, use of the BYADDRESS value can provide a dramatic performance boost. For example, consider a mirrored set consisting of disk devices having their own cache. If the application data is larger than the cache memory of the disk, it might be possible to set the READISTRIBUTION so that the cache memory of each mirrored set member holds a portion of the application data, thus increasing the frequency of read hits from cache memory.

For example, assume a mirrored set that consists of PK 100, 101 and 102, each having a capacity of 3 million sectors. The following command causes the MCP to assign the address space evenly among the online members of the set since no explicit stripe size was provided, as follows:

MIRROR OPTION PK 101 RD = BYADDRESS

The address space is assigned as follows:

  • PK 100 is assigned addresses 0 through 999,999

  • PK 101 is assigned addresses 1,000,000 through 1,999,999

  • PK 102 is assigned addresses 2,000,000 through 2,999,999

Note that if PK 100 is offline (not ready) at the time the command is entered, the system assigns address 0 through 1,499,999 to PK 101 and addresses 1,500,000 through 2,999,999 to PK 102. When PK 100 returns online, the system automatically divides the address space in thirds between all three online members.

MIRROR OPTION PK <unit number> READDISTRIBUTION BYADDRESS STRIPESIZE = <number> SECTORS

MIRROR OPTION PK <unit number> RD BA SS = <number> SECTORS

The STRIPESIZE specification instructs the system to logically divide the address space for the mirrored set into sections (or stripes) of the specified size and then assign the stripes to the online members. For example, a stripe size of 1 million means that the first million sectors of the address space are assigned to the first member of the set, the second million sectors are assigned to the second member, and so on.

Since the BYADDRESS qualifier does not use rotation of address space, it is a good idea to choose a stripe size that involves all members of the mirrored set. This selection ensures that a member does not go unnoticed, if broken. Read operations that are directed to multiple address regions of the set can be directed to one member, while read operations to other regions are directed to different members. This interleaving of the read distribution might be better suited to a random read environment.

For example, assume a mirrored set that consists of PK 500 and PK 600, each member having a capacity of 8 million sectors. The following command assigns the address space in stripes of 2 million sectors:

MIRROR OPTION PK 600 RD = BA SS = 2000000 SECTORS

The preceding command assigns address ranges as follows:

  • PK 500 is assigned addresses 0 through 1,999,999

  • PK 600 is assigned addresses 2,000,000 through 3,999,999

  • PK 500 is assigned addresses 4,000,000 through 5,999,999

  • PK 600 is assigned addresses 6,000,000 through 7,999,999

Note that if PK 500 is offline (not ready) at the time the command is entered, all reads are directed to PK 600. When PK 500 returns online, the address space is automatically divided as previously described.

If a third member, PK 700, is added to this mirrored set, the address space is assigned as follows:

  • PK 500 is assigned addresses 0 through 1,999,999

  • PK 600 is assigned addresses 2,000,000 through 3,999,999

  • PK 700 is assigned addresses 4,000,000 through 5,999,999

  • PK 500 is assigned addresses 6,000,000 through 7,999,999

As another example, assume a mirrored set that consists of PK 900 and PK 920, each member having a capacity of 4 million sectors. The following command assigns the address space in stripes of 3 million sectors:

MIRROR OPTION PK 900 RD = BA SS = 3000000 SECTORS

The address space is assigned as follows:

  • PK 900 is assigned addresses 0 through 2,999,999

  • PK 920 is assigned addresses 3,000,000 through 3,999,999

MIRROR OPTION PK <unit number> MANUALSYNC ON

MIRROR OPTION PK <unit number> MANUALSYNC +

Both of these commands turn on the MANUALSYNC option for PK <unit number>. Operator acknowledgement is required before a mirror audit is applied to PK <unit number>.

MIRROR OPTION PK <unit number> MANUALSYNC OFF

MIRROR OPTION PK<unit number> MANUALSYNC −

Both of these commands turn off the MANUALSYNC option for PK <unit number>. The MCP automatically applies mirror audits when PK <unit number> becomes useable again.

MIRROR OPTION PK <unit number> MANUALSYNC

This command displays the current setting of MANUALSYNC for PK <unit number>.

MIRROR OPTION PK <unit number> RECOVERY = DMS

The DMS value enables faster recovery for packs used solely by DMSII or a program with a similar audit mechanism. In the event of a halt/load, such an audit mechanism reissues outstanding write operations to ensure that the mirrored packs are updated to an identical state.

If the outstanding write list (OWL) is lost and the DMS option is set, the mirrored packs are brought up as a set after a halt/load and are not necessarily identical.

You can select the RECOVERY option for an entire mirrored set by specifying the option for any one of its members.

Note: Do not use the DMS option if the pack includes items that are not audited. For example, you should put the DMSII database control file on a mirrored pack that does not have RECOVERY = DMS specified. If you specify the DMS option for sets that include items that are not audited, the sets might not be identical and might give inconsistent results on future read operations.

MIRROR OPTION PK <unit number> RECOVERY = DISCARD

Setting the DISCARD option breaks the mirrored set; only one pack is brought online if the OWL is lost. RECOVERY = DISCARD is the default setting.

MIRROR OPTION PK <unit number> SPARE ON

MIRROR OPTION PK <unit number> SPARE OFF

Establishes a spare disk pool of disk packs for the Mirrored Disk Pooling Facility (MDPF). This pool contains two classes of spare disks: in-use spares (on-line members of a mirrored set) and free spares (available for assignment to a mirrored set). SPARE ON (or SPARE +) sets the in-use spare attribute in the label of the specified pack. SPARE OFF (or SPARE −) resets the in-use spare attribute.

Use the following options to initially establish the pool of in-use spare disks and thereafter to manually add disks to or delete disks from that pool.

Note: Use the RC (Reconfigure Disk) command to identify a disk as a free spare.
  • SPARE ON. Enters all online members of the mirrored set into the MDPF spare disk pool. This pool is a collection of disks available for automatic replacement of failed mirrors. If your system does not have MDPF installed, the command is rejected and the following RSVP message appears:

    <mix #> PK<unit number> REQUEST REJECTED:
    THE REQUIRED FEATURE KEY IS NOT INSTALLED

    A system message and a status change message are generated for each member successfully added to the spare disk pool. The status change message is defined in the MCP System Interfaces Programming Reference Manual. The following system message appears:

    PK <unit number> ADDED TO THE SPARE DISK POOL
  • SPARE OFF. Removes all members of the mirrored set from the MDPF spare disk pool. If your system does not have MDPF installed, the command is rejected and the following system message appears:

    <mix #> PK<unit number> REQUEST REJECTED:
    THE REQUIRED FEATURE KEY IS NOT INSTALLED

    A system message and a status change message are generated for each member successfully removed from the spare disk pool. The status change message is defined in the MCP System Interfaces Programming Reference Manual. The following system message appears:

    PK <unit number> REMOVED FROM THE SPARE DISK POOL

    When a mirrored set previously assigned to the spare disk pool has been moved to a system that does not support MDPF, its members are not recognized as spare disks. The in-use spare attribute can be cleared from the pack labels with no operator notification.

MIRROR RELEASE PK <unit number>

Eliminates one or more packs from a mirrored set. When mirrors are released, they are automatically taken offline and their labels are invalidated, with one exception: if only one pack remains, it is left online. When all but one member are released, the remaining member is modified to indicate that it is no longer mirrored, and the set is eliminated from the system mirror structures.

Note: The MIRROR RELEASE command has no effect on the time limit assigned to either the released or remaining members of a mirrored set.

MIRROR RELEASE ALL COPIES OF PK <unit number>

Releases all mirrors in a set, except the unit specified, from the mirrored set and takes them offline. The remaining member remains online, and its label is updated to show that it is no longer mirrored.

MIRROR RELEASE OFFLINE COPIES OF PK <unit number>

Releases only offline members of the mirrored set. (An offline member is one in the process of being audited.)

MIRROR SHOW AUDIT

Produces a report of all mirrored sets on the system that have offline members being audited.

MIRROR SHOW AUDIT <family A> <family B> . . .

Produces a report of all mirrored sets in the supplied list of families that have offline members being audited.

Examples

MIRROR SHOW AUDIT
  AVAIL273
       #1 (  273)
  BAKPK
      #3 (1472)  #6 ( 930)  #7 (   80)
  DISK00
      #1 ( 802)  #2 ( 184)  #3 (  272)
    .
    .
    .
  ZEBRA
      #7 (  800) 
MIRROR SHOW AUDIT ZEBRA BAKPK
  ZEBRA
      #7 ( 800)
  BAKPK
      #3 (1472)  #6 ( 930)  #7 (   80)

Considerations for Use

Mirrored disks that had write operations in progress when the system underwent a halt/load are placed into a pending state during system initialization to synchronize the data of the mirrored copies. If the system undergoes a halt/load while a mirror is in the pending state, the mirror is removed from its set during the subsequent system initialization.

Note: If OP + OKTIMEANDDATE was specified before a halt/load, system initialization pauses while it waits for the operator to reply to the RSVP message PLEASE VERIFY TIME AND DATE. Mirrors of critical unitssuch as the halt/load family, the log family, and the catalog family that had write operations in progress when the system underwent a halt/load are in the pending state described previously until the operator responds to the RSVP message. Therefore, if the system undergoes a halt/load during the RSVP process, the mirrors of critical units are lost.

In general, all members of a mirrored set share the same time limit value. The default time limit for disk READ and WRITE operations is 80 seconds. If the IOTIMER command or the SETSTATUS interface is used to change the time limit for a unit that is a member of a mirrored set, the change also applies to the other members of the set.

Disk Mirroring with VSS-2 and VSS-3 Disks

Some restrictions apply to the use of mirrored sets containing various combinations of VSS-1, VSS-2, VSS-3 or 180-byte disks. For a general description of VSS disks, refer to the Peripherals Information File.

VSS-1 continues to be available for mirroring all pre-existing 180-byte sector disks with 512-byte sector disks.

A 180-byte disk cannot be mirrored onto a VSS-2 disk, unless the 180-byte disk was reconfigured with the VSS = VSS2 option of the RC command.

A 180-byte disk cannot be mirrored onto a VSS-3 disk, unless the 180-bytes disk was reconfigured with the VSS=VSS3 option of the RC command.

A VSS-2 disk cannot be mirrored onto a VSS-3 disk, unless the VSS-2 disk was reconfigured with the VSS=VSS3 option of the RC command.

If you enter a MIRROR CREATE command that specifies a VSS-2 disk as the destination and a VSS-1 or incompatible 180 byte disk as the source, the system replies with the following message:

  NOT ALLOWED: Destination must be INITIALIZED as VSS-1 and RCED
  with CAPACITY option to mirror this source.

To convert the selected disk to a compatible destination for this source

  1. If the disk is labeled, enter the following command:

    INITIALIZE PK <destination disk> OLDNAME = <name> VSS = VSS1

    If the disk is not labeled, enter the following command:

    INITIALIZE PK <destination disk> VSS = VSS1
  2. Enter the following command:

    RC PK <destination disk> NAME = <temp name> 
    SERIAL = <temp serial> CAPACITY LIKE PK <source disk>

A VSS-2 disk cannot be mirrored onto a VSS-1 disk. Likewise, a 180-byte disk with the VSS=VSS2 attribute cannot be mirrored onto a VSS-1 disk. If you enter a MIRROR CREATE command that violates one of these restrictions, the system displays the following message:

  NOT ALLOWED: Destination must be INITIALIZED as VSS-2 and RCED
  with CAPACITY option to mirror this source.

To convert the selected disk to a compatible destination for this source, enter the following system commands:

  1. If the disk is labeled, enter the following command:

    INITIALIZE PK <destination disk> OLDNAME = <name> VSS = VSS2

    If the disk is not labeled, enter the following command:

    INITIALIZE PK <destination disk> VSS = VSS2
  2. Enter the following command:

    RC PK <destination disk> NAME = <temp name>
     SERIAL = <temp serial> CAPACITY LIKE PK <source disk>

The following chart shows the various source-target combinations and indicates whether a MIRROR CREATE is allowed for each.

Source

Target

Allowed (9)

180-byte

180-byte

Yes

180-byte

180-byte(1)

Yes(2)

180-byte

180-byte(6)

Yes(7)

180-byte

VSS-1

Yes

180-byte

VSS-2

No(13)

180-byte

VSS-2(8)

No(13)

VSS-1

180-byte

Yes

VSS-1

180-byte(1)

Yes(2)

VSS-1

180-byte(6)

Yes(7)

VSS-1

VSS-1

Yes

VSS-1

VSS-2

No(13)

VSS-1

VSS-2(8)

No(13)

VSS-2

180-byte

Yes(3)

VSS-2

180-byte(1)

Yes

VSS-2

180-byte(6)

Yes(3)

VSS-2

VSS-1

No(14)

VSS-2

VSS-2

Yes

VSS-2

VSS-2(8)

Yes(10)

180-byte(1)

180-byte

Yes(3)

180-byte(1)

180-byte(1)

Yes

180-byte(1)

180-byte(6)

Yes(3)

180-byte(1)

VSS-1

No(14)

180-byte(1)

VSS-2

Yes

180-byte(1)

VSS-2(8)

Yes(10)

180-byte(6)

180-byte

Yes(4)

180-byte(6)

180-byte(1)

Yes(4)

180-byte(6)

180-byte(6)

Yes

180-byte(6)

VSS-1

No(14)

180-byte(6)

VSS-2

Yes(5)

180-byte(6)

VSS-2(8)

Yes

VSS-2(8)

180-byte

Yes(4)

VSS-2(8)

180-byte(1)

Yes(4)

VSS-2(8)

180-byte(6)

Yes

VSS-2(8)

VSS-1

No(14)

VSS-2(8)

VSS-2

Yes(5)

VSS-2(8)

VSS-2(8)

Yes

VSS-2(11)

180-byte

No

VSS-2(11)

180-byte(1)

No

VSS-2(11)

180-byte(6)

No

VSS-2(11)

VSS-1

No(14)

VSS-2(11)

VSS-2

Yes(12)

VSS-2(11)

VSS-2(8)

Yes(10)(12)

VSS-2(8)(11)

180-byte

No

VSS-2(8)(11)

180-byte(1)

No

VSS-2(8)(11)

180-byte(6)

No

VSS-2(8)(11)

VSS-1

No (14)

VSS-2(8)(11)

VSS-2

Yes(5)(12)

VSS-2(8)(11)

VSS-2(8)

Yes(12)

Notes:
  1. The 180-byte disk is reconfigured with VSS = VSS2

  2. The target 180-byte disk no longer uses VSS-2 file allocation after this mirror create operation.

  3. The target 180-byte disk uses VSS-2 file allocation after this mirror create operation is started.

  4. The target 180-byte disk uses VSS-3 file allocation after this mirror create operation is started.

  5. The target VSS-2 disk uses VSS-3 file allocation after this mirror create operation is started.

  6. The 180-byte disk is reconfigured with VSS = VSS3.

  7. The target 180-byte disk no longer uses VSS-3 file allocation after this mirror create operation is started.

  8. The VSS-2 disk is reconfigured with VSS=VSS3.

  9. The target must have the same capacity as the <source> mirror.

  10. The target VSS-2 disk no longer uses VSS-3 file allocation after this mirror create operation is started.

  11. The source disk has encryption enabled.

  12. The target disk uses encryption after this miror create operation is started.

  13. The VSS-2 target must be initialized to VSS-1 and reconfigured with CAPACITY LIKE PK <source> to mirror this source.

  14. The VSS-1 target must be initialized to VSS-2 and reconfigured with CAPACITY LIKE PK <source> is started.

The Mirrored Disk Pooling Facility (MDPF) follows the same rules when selecting a disk from the spare disk pool for mirror replacement. The following table identifies the spares eligible to replace a released mirror.

Released Mirror

Spare Disk

Eligible Candidate (1)

180-byte

180-byte

Yes

180-byte

180-byte with VSS=VSS2

Yes (2)

180-byte

180-byte with VSS=VSS3

Yes (3)

180-byte

VSS-1

Yes

180-byte

VSS-2

No

180-byte with VSS=VSS2

180-byte

Yes (4)

180-byte with VSS=VSS2

180-byte with VSS=VSS2

Yes

180-byte with VSS=VSS2

180-byte with VSS=VSS3

Yes (4)

180-byte with VSS=VSS2

VSS-1

No

180-byte with VSS=VSS2

VSS-2

Yes

180-byte with VSS=VSS3

180-byte

Yes (5)

180-byte with VSS=VSS3

180-byte with VSS=VSS2

Yes (5)

180-byte with VSS=VSS3

180-byte with VSS=VSS3

Yes

180-byte with VSS=VSS3

VSS-1

No

180-byte with VSS=VSS3

VSS-2

Yes (5)

VSS-1

180-byte

Yes

VSS-1

180-byte with VSS=VSS2

Yes (2)

VSS-1

180-byte with VSS=VSS3

Yes (3)

VSS-1

VSS-1

Yes

VSS-1

VSS-2

No

VSS-2

180-byte

Yes (4)

VSS-2

180-byte with VSS=VSS2

Yes

VSS-2

180-byte with VSS=VSS3

Yes (4)

VSS-2

VSS-1

No

VSS-2

VSS-2

Yes

VSS-2 with VSS=VSS3

180-byte

Yes (5)

VSS-2 with VSS=VSS3

180-byte with VSS=VSS2

Yes (5)

VSS-2 with VSS=VSS3

180-byte with VSS=VSS3

Yes

VSS-2 with VSS=VSS3

VSS-1

No

VSS-2 with VSS=VSS3

VSS-2

Yes (5)

VSS-2 Encrypted

180-byte

No

VSS-2 Encrypted

180-byte with VSS=VSS2

No

VSS-2 Encrypted

180-byte with VSS=VSS3

No

VSS-2 Encrypted

VSS-1

No

VSS-2 Encrypted

VSS-2

Yes

VSS-2 with VSS=VSS3Encrypted

180-byte

No

VSS-2 with VSS=VSS3Encrypted

180-byte with VSS=VSS2

No

VSS-2 with VSS=VSS3Encrypted

180-byte with VSS=VSS3

No

VSS-2 with VSS=VSS3Encrypted

VSS-1

No

VSS-2 with VSS=VSS3Encrypted

VSS-2

Yes (5)

Notes:
  1. Any eligible candidate has the same capacity as the released mirror.

  2. The target disk no longer uses VSS-2 file allocation after this mirror replacement is started.

  3. The target disk no longer uses VSS-3 file allocation after this mirror replacement is started.

  4. The target disk uses VSS-2 file allocation after this mirror replace is started.

  5. The target disk uses VSS-3 file allocation after this mirror replace is started.