MGMTclas REPDELAY Parameter

This update applies to the ELS 7.3 Command, Control Statement, and Utility Reference.

The VTCS MGMTclas control statement adds the REPDELAY parameter used to specify a delay time for asynchronous replication.

Syntax

For reference, the following figure shows complete syntax for the MGMTclas control statement, including the added REPDELAY parameter.

Figure 2-5 MGMTclas Control Statement Syntax

Description of "Figure 2-5 MGMTclas Control Statement Syntax"

Parameters

The MGMTclas control statement adds the REPDELAY parameter. For reference, all MGMTclas parameters are described as follows:

NAME(mgmt-class-name)

specifies the name of the Management Class.

mgmt-class-name indicates the Management Class name. This name must be one to eight alphanumeric characters beginning with an alpha character and must follow SMS naming conventions.

ACSlist(acs-id or acs-id,acs-id)

optionally, specifies the ACSs from which RTDs and MVCs are selected. If not specified, the default is the ACS specified on the CONFIG DEFLTACS parameter. See DUPlex, below, for information about using the DUPlex and ACSlist parameters.

acs-id or acs-id,acs-id indicates either one or two ACS IDs. An ACSid is a two digit decimal ACS identifier from 00-99.

ARCHAge(nnn)

optionally, specifies the age (in days) of a VTV before it is archived as specified by ARCHPol. If you specify ARCHAge, you must specify ARCHPol.

This parameter is optional; there is no default value. Valid values are 1 to 999.

nnn indicates the VTV age in days.

ARCHPol(stor-class-name or stor-class-list)

optionally, specifies up to four Storage Classes that specify the ACS and media type of the archive MVCs.

If you specify one Storage Class, VTCS archives one copy of a VTV.
If you specify multiple Storage Classes (with different ACS values, different MEDIA values, or both), VTCS archives multiple copies of the VTV to different MVCs in different ACSs.
If you specify multiple Storage Classes with identical ACS and MEDIA values, VTCS archives multiple copies of the VTV to the same ACS and media type but to different MVCs.

Note:

Multiple Storage Classes on ARCHPol also affects how VTV recall, MVC space reclamation, and VTV consolidation function.

This parameter is optional; there is no default value. If you specify ARCHPol, you must specify ARCHage.

stor-clas-name1...stor-clas-namen indicates the names of one or more Storage Classes that you defined on the STORclas control statement. Greater than two copies requires you to specify CDSLEVEL(V6ABOVE) or CDSLEVEL(V6ABOVE) on the CONFIG statement.

CONSRC(stor-class-name)

optionally, specifies the Storage Class that species a preference for the source MVC ACS and media for consolidation of VTVs that are migrated and copied to multiple MVC locations or media types. If the MVC in the specified Storage Class is unavailable, and the specified Storage Class is not the last (in order specified in the migration policy), VTCS uses the MVC associated with the last Storage Class. If the MVC in the specified Storage Class is unavailable and the specified Storage Class is the last (in order specified in the MIGpol parameter), VTCS uses the MVC associated with the previous Storage Class (in order specified in the MIGpol parameter).

stor-class-name indicates the name of a Storage Class that you defined on the STORclas control statement.

CONTGT(stor-class-name)

optionally, specifies the Storage Class that determines the output MVC ACS and media for VTV consolidation (executing CONSolid, EXPORT VTV or EXPORT MGMTclas). Note that the media preferencing is in the opposite order of the list of media types specified on the Storage Class.

This parameter is optional; there is no default value. If you do not specify a value for CONTGT, VTCS selects the output MVC as follows:

For single-ACS and dual-ACS configurations, the media selection order for VTV consolidation.
For multiple ACS systems, VTCS selects MVCs from the default ACS specified by the CONFIG DEFLTACS parameter.

stor-class-name indicates the name of a Storage Class that you defined on the STORclas control statement.

DELSCR

optionally, specifies whether VSM deletes scratched VTVs.

NO: Do not delete scratched VTVs (the default).; If you are using the pinning feature enabled in the MGMTclas control statement, resident replica copies are deleted when the VTV is scratched. The primary copy is not deleted until migration time. Once a VTV is scratched, it is no longer pinned.
YES: Delete scratched VTVs unless this would cause a processing delay due to unavailable resources.
FORCE: Delete scratched VTVs and wait for access to any resources that are required. This may cause a processing delay.

Note:

When you scratch a VTV wit the DELSCR YES attribute, VSM erases the VTV data at scratch synchronization time, which eliminates the ability to "unscratch" a VTV to recover data!

Also note that when using HSC to perform scratch synchronization, it is possible that a volume that is scratch in the TMC at the beginning of scratch synchronization run and also scratch in the CDS from the previous scratch update run (and thus is in the list for HSC to scratch in the CDS) is accessed by a job during the scratch update run and written to and made non-scratch by the TMS in the TMC. In this case, it is still possible for HSC to scratch the volume because it was in the originally extracted list of volumes to be scratched. Therefore, Oracle strongly recommends that you do not run any jobs that use scratches during HSC scratch synchronization.

Refer to the LCM User’s Guide for more information about LCM scratch synchronization with the SYNCVTV function.

DISCARD(nnnn)

optionally, specifies the discard time in hours. This value represents the time after a VTV is dismounted that the VTV is kept in the buffer. After this time value expires, the VTV is preferred for deletion from the VTSS buffer if all required copies of the VTV exist on MVCs.

nnnn indicates the time in hours. Valid values are 0 to 9999. The default is 9999.

When IMMEDmig is specified, DISCARD is not used for immediate migration processing. It is only applicable for AUTO migration requests. If RESTIME is also specified for a VTV, it overrides the DISCARD value.

DUPlex

optionally, specifies whether VSM will migrate two copies of the VTV to two MVCs. DUPlex and MIGpol are mutually exclusive.

NO: Do not duplex the VTV (the default).
YES: Duplex the VTV.

The following table describes possible scenarios using the DUPlex and ACSlist parameters:

Table 2-1 MGMTclas ACSlist/DUPlex Scenarios

DUPlex Setting	ACSlist Setting	Action
YES	Two ACSs	VSM migrates the VTVs to two MVCs, one in each ACS. (This scenario is the normal one for duplexing to two ACSs.)
YES	One ACS	VSM migrates the VTVs to two MVCs in the ACS specified.
NO	Two ACSs	VSM ignores the `DUPlex` policy and migrates the VTVs to two MVCs, one in each ACS.
NO	One ACS	VSM migrates the VTVs to one MVC in the ACS specified.

MIGpol(s1 or s1,s2 or s1,s2,s3 or s1,s2,s3,s4)

optionally, specifies up to four Storage Classes that specify the ACS and media type of migration MVCs. DUPlex and MIGpol are mutually exclusive.

If you specify one Storage Class, VTCS migrates one copy of a VTV.
If you specify multiple Storage Classes (with different ACS values, different MEDIA values, or both), VTCS makes multiple copies the VTV to different MVCs in different ACSs.
If you specify multiple Storage Classes with identical ACS and MEDIA values, VTCS makes multiple copies of the VTV to the same ACS and media type but to different MVCs.

Note:

Multiple Storage Classes on MIGpol also affects how VTV recall, MVC space reclamation, and VTV consolidation function.

This parameter is optional; there is no default value.

s1 or s1,s2 or s1,s2,s3 or s1,s2,s3,s4 indicates the names of up to four Storage Classes you defined on the STORclas control statement. Greater than two copies requires you to specify CDSLEVEL(V61ABOVE) or greater on the CONFIG statement.

Note:

The CONFIG GLOBAL REPLicat parameter specifies when to replicate a VTV (always, or only when changed while mounted).

EEXpol(s1 or s1,s2)

optionally, specifies the storage classes for electronic export.

s1 or s1,s2 indicates a maximum of two Storage Classes that specify the TAPEPLEX parameter. If these storage classes do not specify the TAPEPLEX parameter, an error condition results.

If there are two TAPELEX storage classes, then they must specify different destination TapePlex names.
A warning will be generated if the two TapePlex storage classes are specified with the SYNC=YES parameter. It is only possible to synchronously export to one other TapePlex.
If there is a conflict, electronic export functionality takes precedence over replication with a cluster.
If either one of the storage classes referenced contains the THISPLEX name, then the storage class is silently ignored. This enables common storage class definitions to be applied across TapePlexes.

IMMDELAY(nnnn)

optionally, specifies the immediate migration delay time; the amount of time after VTV dismount that the migration should be queued for action. This enables VTVs used in multi-step jobs to remain resident for a specified time before being processed for migration.

nnnn indicates the immediate migration delay time in minutes. Valid values are 0 to 9999 (the default).

If IMMDELAY=9999 then immediate migration does not occur. Migration and deletion is handled through auto or command migration.

When this value is specified, MIGRSEL and MIGRVTV have no influence on migration control.

RESTIME and DISCARD parameter values represent buffer management priorities:

If the IMMDELAY value is less than the RESTIME value, keep the VTD in the VTSS as a priority.
If the IMMDELAY value is greater than the RESTIME value but less than the DISCARD value, manage the buffer according to LRU (default state).
If the IMMDELAY value is greater than the DISCARD value, remove the VTD from the VTSS as a priority.

The IMMDELAY parameter is designed to replace the IMMEDmig parameter, described in Oracle’s ELS publication ELS Legacy Interfaces Reference. These parameters are mutually exclusive. The following table describes equivalent values:

Table 2-2 IMMDELAY and IMMEDmig Equivalent Values

IMMDELAY or DISCARD Values	IMMEDmig Value	Action
IMMDELAY(1-9998)	None	Delay migration for the specified number of minutes.
IMMDELAY(9999)	IMMED(NONE)	VSM does not immediately migrate the VTV, but migrates it according to standard VSM migration criteria. `MIGRSEL` and `MIGRVTV` have no influence on migration control.
IMMDELAY(0)DISCARD(9999)	IMMED(KEEP)	VSM immediately migrates a VTV and keeps a copy resident on the VTSS until the VTV becomes eligible for deletion.
MMDELAY(0)DISCARD(0)	IMMED(DELETE)	VSM immediately migrates the VTV and then deletes it from the VTSS.

Note:

If you specify REPlicat YES or YES_SYNC, VTCS defaults to IMMDELAY 0. If you specify REPlicat YES or YES_SYNC in combination with IMMDELAY 9999, VTCS ignores the IMMDELAY parameter without issuing a message. For example:

MGMT NAME(REPIMNO) REP(YES) IMMDELAY(9999)

causes VTCS to use IMMDELAY 0 and perform immediate migration. To suppress immediate migration, add a MIGRVTV MGMTclas(x) IMMDELAY(9999) statement for the management class.

MAXVtvsz

optionally, specifies the maximum size for VTVs in this Management Class. Valid values for this parameter depend on both the CDS level and the microcode levels of the applicable VTSSs.

400: 400 MB. This is the default.
800: 800 MB. The CDS must be at a E level or above.
2000: 2 GB. The CDS must be at a G level or above.
4000: 4 GB. The CDS must be at a G level or above.
32000: 32 GB. The CDS must be at an I level or above.

Considerations:

The size of a VTV changes only after it goes through a scratch cycle. Therefore, if you change the Management Class and DISP=MOD, then it will still retain the original size.
If you specify a VTV size that is not supported by the configuration, VTCS issues warning messages and MAXVtvsz defaults to the largest VTV size supported by the configuration.
MAXVtvsz does not apply to VSM2s.
MAXVTVSZ(2000 | 4000) requires VSM4 or VSM5 microcode D02.02.00.00 or VSM3 microcode N01.00.77.00. No installed option is required.
MAXVTVSZ(32000) requires VSM6 minimum microcode level 6.2 and VLE minimum microcode level 1.5.1, if VLE is in the configuration.

NOMIGRAT

optionally, specifies that VTVs in the Management Class are not candidates for migration, consolidation or export, but are candidates to reside on a tapeless VTSS.

VTSS selection is changed to prefer tapeless VTSSs for VTVs in Management Classes with NOMIGRAT, and to disallow VTVs without NOMIGRAT from VTSSs with no RTDs.

NOMIGRAT is mutually exclusive with ACSLIST, IMMDELAY, DUPLEX, MIGPOL, ARCHAGE, ARCHPOL, RESTIME, CONSRC and CONTGT.

REPlicat

optionally, specifies whether VSM replicates the VTV.

Synchronous replication must be enabled through the CONFIG GLOBAL SYNCHREP parameter.

causes VTCS to use IMMDELAY 0 and perform immediate migration.

To suppress immediate migration, add a MIGRVTV MGMTclas(x) IMMDELAY(9999) statement for the management class.

NO: Do not replicate the VTV (the default).
YES: Asynchronously replicate the VTV.
YES_SYNC: Synchronously replicate the VTV.

RESTIME(nnnn)

optionally, specifies how long VTCS attempts to keep a VTV as VTSS-resident before becoming a preferred automatic migration candidate.

This parameter is optional; there is no default value. Valid values are 1 to 9999. Value 9999 specifies that the VTVs in this Management Class are resident permanently unless VTSS space management requires VTCS to automigrate the VTV and then delete it from the VTSS.

nnnn indicates the residency time in hours.

RESTIME and IMMEDmig(DELETE) are mutually exclusive. RESTIME takes effect when a VTV is created, and does not apply to a recalled VTV.

VTVPAGE

optionally, specifies that the page size used to store VTV data in the VTSS and on the MVCs. This setting only applies to 400 MB and 800 MB VTVs. If VTVPAGE is not specified on either the MGMTclas statement or the CONFIG GLOBAL statement, the default is STANDard.

STANDARD: standard page size, which is compatible with all VSM3 or VSM4 models and microcode levels.
LARGE: large page size, which can provide improved performance within the VTSS and for migrates and recalls. Large page size requires a G level CDS. For 2 GB, 4 GB, or 32 GB VTVs (MAXVtvsz 2000, 4000, or 32000), a VTVPAGE setting of LARGE is always used.

Considerations:

VTVPAGE does not apply to VSM2s. VTVPAGE(LARGE) requires VSM4 or VSM5 microcode D02.02.00.00 or VSM3 microcode N01.00.77.00. No installed option is required.
MGMTCLAS VTVPAGE, if specified, overrides the CONFIg GLOBAL VTVPAGE value. If VTVPAGE is not specified on either the MGMTclas statement or the CONFIg GLOBAL statement, the default is STANDard.
The page size of a VTV can only be changed by a VTV scratch mount. Additional restrictions may also apply for scratch VTVs that were previously resident in a VTSS.
If you specify LARGE and the CDS level and/or VTSS microcode do not support LARGE, VTCS issues warning messages and VTVPAGE defaults to STANDard.
If you specify STANDard for 2 GB or 4 GB VTVs VTCS issues warning messages and defaults to LARGE.
Creating VTVs with large pages makes these VTVs unreadable in configurations that do not support large VTV pages.
The VTVPAGE value specified for this Management Class overrides the global value specified on the CONFIg utility.

WRITE

optionally, specifies the VTSS-resident VTV VOLSAFE policy as follows:

MANY

specifies no VOLSAFE write protection. This is the default.

ONCE

specifies partial (write once) VOLSAFE protection. After the VTV is non-scratch, it cannot be overwritten or appended.

APPEND

specifies full VOLSAFE protection. This is only supported for VSM6 systems.

VTV data can be appended once non-scratch.
Data cannot be overwritten.

The Display VTV command and VTVRPT report will indicate that the VTV is write-append protected.

VTVs with full VOLSAFE protection can only be scratched with RACF ALTER authority. Use the following RACF commands to set RACF authority:

RDEFINE TAPEVOL volser UACC(NONE)
PERMIT volser CLASS(TAPEVOL) ID(userid) ACCESS(ALTER)

EDLTeexp

optionally, specifies whether pending Electronic Export VTVs are candidates for early deletion. The VTVs will only be deleted if all CLINKs to the remote Tapeplex are not operational. The EDLTeexp option requires that the EEXPOL and MIGPOL policies be set for the management class.

Note:

For the early delete VTVs to be electronically exported, you must run the VTCS RECONCIL utility after the remote Tapeplex CLINKs are varied ONLINE.

PINpol(vtss-name or vtss-list-name)

optionally, specifies one or two VTV pinning locations where a resident replica of a VTV is stored in the VTSS buffer. A location can be either a vtss-name or vtss-lst-name.

vtss-name indicates a VTSS name.

vtss-list-name indicates the name of a VTSS list (as specified in a MGMTDEF VTSSLST control statement). This value can be a maximum of 8 alphanumeric characters, with the first character in the range of A-Z.

If two locations are specified, there must also be a replication (REPlicat) policy defined on the MGMTCLAS statement.

Note:

Only pin VTVs that are required to stay resident. Pinning every VTV or too may VTVs can cause the VTSS to fill to capacity and become unusable.

For pinning to function correctly, PTF L1H18UI (adds VTV pinning support) must be applied to all systems, and the MGMTclas statements with a pinning policy must be defined on all hosts.

REPDELAY(nnnn)

optionally, specifies the asynchronous replication and/or asynchronous electronic export delay time, the minimum amount of time after a VTV is dismounted that the asynchronous replication and/or asynchronous electronic export will be delayed.

nnnn indicates the delay time in minutes. Valid values are 0 (the default) to 9999.

REPDELAY(nnnn) requires either REPLICAT or EEXPOL. If both REPLICAT(YES) and EEXPOL are specified on the same MGMTCLAS then the asynchronous replication and asynchronous electronic export will both be delayed by the time specified.
REPDELAY is ignored for synchronous replication and synchronous electronic export.
REPDELAY is honored across varying a VTSS offline or online. When the VTSS is varied back online and the delay time has not expired then the VTV(s) will continue to be delayed. If the delay time has expired then the VTV(s) will be replicated once the VTSS is online.
REPDELAY is not honored across cycling HSC. Once HSC or VTCS is fully initialized the VTV(s) will be replicated.