2 Planning VTCS Operating Policies

This chapter describes the VTCS operating policies. You must set your VTSS AMTs, as described in "AMT Settings." Otherwise, you can just take the defaults, let the system run for a while, and see what is working or not working and adjust accordingly.

The following sections describe VTCS operating policies:

• "Making CDS Logging Required"

• "Locked Resource Policy"

• "VTSS Policies"

• "General VTV Policies"

• "VTV Migration Policies"

• "VTV Replication Policies"

• "MVC Policies"

Note that these are rough groupings only. All the pieces and parts of VSM interact with each other constantly, so it is impossible to talk VTVs without thinking about MVCs, and vice versa. These policies are set globally on the CONFIG statement^Foot 1 , some of which you can override on a per job basis.

Making CDS Logging Required

Table 2-1 Enable CDS Logging

Policy:	Values:	Default:	Command to Set Policy:
Makes CDS logging required.	LOGPOL=REQuired LOGPOL=OPTional	LOGPOL=OPTional	CONFIG GLOBAL LOGPOL parameter

Usage Notes

• If all copies of the CDS fail, recovery can be time consuming. CDS logging can aid in re-synchronizing the CDS with the data content of the VSM subsystem. Note that recovery using logs will recreate a usable CDS but it may not fully restore VTV and MVC metadata.

• Note that the CONFIG GLOBAL LOGPOL setting merely specifies whether logging is required or optional. For information on setting up logging, see "Defining and Creating CDS Log Files." For information, refer to Managing HSC and VTCS. For your initial configuration, you may want to go with the default (LOGPOL=OPT) and change this value, if desired, when you actually decide to implement logging.

• Logging works as follows:

  • If you specify LOGPOL=REQ and all hosts sharing the CDS are at 7.0 or above, logging is enabled for all systems, which aids recreation of a CDS.

  • If you specify LOGPOL=REQ and some hosts sharing the CDS are at below 7.0, logging is enabled for only 7.0 and above systems, so recovery is from logs for only those hosts. On hosts below 7.0, VTCS does not initialize.

  • If you specify LOGPOL=OPT and some hosts sharing the CDS are at below 7.0, logging is enabled for only 7.0 and above systems, so recovery is from logs for only those hosts. Hosts below 7.0 initialize but do not do logging.

Running IMPORT/EXPORT When Logging Required is Enabled

To run IMPORT/EXPORT when Logging Required is enabled:

1. Back up the CDS.

2. Run CONFIG to turn off logging required.

3. Run the utility.

4. Run CONFIG to re-enable logging required.

5. Back up the CDS.

6. Resume normal activity.

Locked Resource Policy

Table 2-2 shows the locked resource policy.

Table 2-2 Locked Resource Policy

Policy:	Values:	Default:	Command to Set Policy:
Specifies the minimum number of minutes that a resource is locked before message SLS6946E is issued.	Valid values are 0, or any value between 5 and 240. If 0 is specified, message SLS6946E will not be issued when a required resource is locked.	If this parameter is not specified, the current default of 10 minutes is retained.	CONFIG LOCKTOUT=nnn

Note:

LOCKTOUT is only supported at ’F' level CDS (V61ABOVE) and above.

VTSS Policies

The following sections describe these VTSS policies:

• "AMT Settings." AMT settings are critical because they start and stop automatic migration and all its attendant functions. On this one, you have CONFIG settings that you can override with the SET MIGOPT command.

• "Deleting Scratched VTVs." Deleting scratched VTVs can free buffer space but has some associated potential risks, so read the usage notes before enabling this feature.

• "VTV Page Size" and "Maximum VTV Size." These two are linked, and even though they are VTV policies, they are more about optimizing VTSS usage, so they are discussed here. Large VTV page sizes, when matched with the appropriate VTSS model, can optimize performance within the VTSS. VTV page sizes are about the page data size within the VTSS, not the actual VTV size. VTV page sizes, however, are actively linked to VTV sizes, which can improve performance in high-capacity VTSSs. In fact, selecting VTV sizes of 2 or 4 GB enforces a Large VTV Page.

• "Maximum RTDs per VTSS." Your choices are 16 or 32 maximum, and it is a CONFIG GLOBAL setting.

AMT Settings

Table 2-3 shows AMT settings.

Table 2-3 AMT Settings

Policy:	Values:	Default:	Command to Set Policy:
Controls the automatic space management/migration cycle. This cycle begins when DBU (Disk Buffer Utilization) exceeds the high AMT (HAMT) or as described in Table 2-4. AMTs are a percentage of DBU.	LAMT - 5 - 95, must be one less than HAMT. HAMT - 5 - 95, must be one greater than LAMT.	LAMT - 70 HAMT - 80	CONFIG VTSS LOW and HIGH parameters SET MIGOPT HIGHthld and LOWthld parameters.

Table 2-4 shows VTSS Model Maximum VTVs and Automigration Thresholds.

Table 2-4 VTSS Model Maximum VTVs and Automigration Thresholds

VSM Model	Maximum VTVs	Automigration Starts Above
VSM2/VSM3	100,000	97,000
VSM4/VSM5	300,000	291,000
VSMc Models: VSM5-45TB-IFF3 VSM5-68TB-IFF3 VSM5-90TB-IFF3	500,000	485,000
VSM 6	1.000,000	970,000

Usage Notes

• With CONFIG, AMT settings take effect when you start HSC and apply to the specified VTSS.

• With SET MIGOPT:

  • AMT settings take effect immediately and apply to the specified VTSS or if no VTSS is specified, to all VTSSs. If you try to set global values (no VTSS specified) and the values are not valid for one VTSS (for example, MAXMIG(5) and one VTSS only has 4 RTDs connected), VTCS will not set values for any VTSSs.

  • You can set the LAMT, the HAMT, or both.

• The following are general guidelines for changing the defaults:

  • The difference between the high and low AMTs affects the duration of the space management/migration cycle.

  • Lowering the HAMT tends to trigger more frequent space for management/migration cycles.

  • Raising the HAMT tends to trigger less frequent space management/migration cycles.

  • Lowering the LAMT tends to free more VTSS space and migrate more VTVs.

  • Raising the LAMT tends to keep more VTVs resident in VTSS space and migrate fewer VTVs.

Tip: You can use Display VTSS to display the DBU, HAMT, and LAMT for each VTSS in your system. You can also use Display MIGrate to display migration status.

Deleting Scratched VTVs

Table 2-5 Delete Scratched VTVs Settings

Policy:	Values:	Default:	Command to Set Policy:
Specifies whether VSM deletes scratched VTVs.	NO, YES, FORCE	NO	MGMTCLAS DELSCR

Usage Notes

• Specifying DELSCR(YES) deletes scratch VTVs unless this would cause a processing delay due to unavailable resources.

• Specifying DELSCR(FORCE) waits for access to any resources that are required and deletes scratch VTVs, which may cause a processing delay.

• Specifying DELSCR(YES) or DELSCR(FORCE) causes VSM to delete scratched VTVs, which frees VTSS buffer space and (logically) deletes any VTV copies from MVCs so that MVC space can be reclaimed.

Note:

As an alternative, you can take the default DELSCR(NO) and, as needed, run the DELETSCR NOTREF command to delete scratch VTVs (from the VTSS and MVCs) n days after the VTV was last referenced. For more information, refer to the ELS Command, Control Statement, and Utility Reference.

Caution:

• When you scratch a VTV with DELSCR YES or FORCE attribute, VSM erases the VTV data at scratch synchronization time, which eliminates the ability to "unscratch" a VTV to recover data.

• When using SLUCONDB to synchronize scratches, it is important to avoid the following to avoid inadvertently scratching a VTV resulting in data loss at scratch synchronization time:

  • Running the HSC SLUADMIN Scratch Update Utility at the same time that SLUCONDB is running.

  • Not specifying the current TMS database and/or the current HSC CDS when using SLUCONDB.

For more information about HSC scratch synchronization with the Scratch Conversion Utility (SLUCONDB), refer to the ELS Command, Control Statement, and Utility Reference.

Also note that for HSC and MVS/CSC, the DELDISP parameter has two values that affect how HSC manages the scratch status of VTVs and real volumes that were mounted scratch and the delete disposition on the dismount message is delete ('D').

• For more information about LCM scratch synchronization with the SYNCVTV function, refer to the LCM User's Guide.

VTV Page Size

Table 2-6 VTV Page Size

Policy:	Values:	Default:	Command to Set Policy:
Specifies the default page size used to store VTV data in the VTSS and on the MVCs for 400 and 800 MB VTVs only. For 2 GB and above VTVs, a VTVPAGE setting of LARGE is always used.	STANDARD or LARGE	STANDARD	CONFIG GLOBAL VTVPAGE MGMTclas VTVPAGE

Usage Notes

• Large page size (which requires that the CDS is at a G level or above) can provide improved performance within the VTSS and for migrates and recalls. For more information about CDS levels, see "CDS VTCS Level Requirements."

Caution:

• 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.

• VTVPAGE does not apply to VSM2s. The VTSS microcode requirements are as follows:

  For VSM3s: microcode level N01.00.77.00 or higher.

  For VSM4s/VSM5s: microcode level D02.02.00.00 or higher.

  For VSM6s, all levels of microcode.

• 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.

• Creating VTVs with large pages makes these VTVs unreadable in configurations that do not support large VTV pages.

Maximum VTV Size

Table 2-7 Maximum VTV Size

Policy:	Values:	Default:	Command to Set Policy:
Specifies the maximum size of a VTV.	400 - 400 Mb. 800 - 800 Mb. The CDS must be at a D 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.	400	CONFIG GLOBAL MAXVTVSZ,MGMTCLAS MAXVTVSZ

Usage Notes

• 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.

Caution:

Specifying 2GB or 4GB VTVs:

• Increases MVC usage.

• May degrade space management of smaller-capacity VTSSs, which have relatively small cache and buffer sizes.

• Increases delays to jobs waiting recalls. Although the actual data transfer time from an MVC is the same and there may be fewer interruptions, each interruption lasts longer, which can cause job time-outs.

• The CONFIG GLOBAL and MGMTCLAS MAXVTVSZ parameters interact as follows:

  • If MAXVTVSZ is specified on MGMTCLAS, this value overrides the CONFIG GLOBAL MAXVTVSZ value.

  • If MAXVTVSZ is not specified on MGMTCLAS, the CONFIG GLOBAL MAXVTVSZ value, if specified, is used. Otherwise, MAXVTVSZ defaults to 400MB.

  • If MAXVTVSZ is not specified on MGMTCLAS or on CONFIG GLOBAL, MAXVTVSZ defaults to 400MB.

Maximum RTDs per VTSS

You can connect up to 32 RTDs per VTSS.

Table 2-8 Maximum RTDS per VTSS - 16 or 32

Policy:	Values:	Default:	Command to Set Policy:
Specifies the maximum RTDs per VTSS.	16, 32	16	CONFIG GLOBAL MAXRTDs

Usage Notes

• For maximum 32 RTDs support, you must fulfill the requirements described in Table H-3.

• The VTCS addressing scheme for maximum 32 RTDs is different than that for maximum 16 RTDs. For more information, see "RTD/CLINK Addresses - Maximum 32 RTDs."

RTD/CLINK Addresses - Maximum 32 RTDs

VSM5 is available only with 8 VCF (FICON) cards in the configuration for a maximum of 32 RTDs shown in Figure 2-1.

Figure 2-1 VSM5 with 8 VCF cards - Max 32 RTDs

As Figure 2-1 shows, each FICON interface supports 4 devices attached using FICON directors. Note that the addressing scheme used by VTCS is different from that used for support of 2 devices per interface. The device addresses are now in the format CI:R, where:

• C is the cluster number (0 or 1)

• I is the interface number (A, C, E, G, I, K, M, or O)

• R is the device number on the interface (0, 1, 2, or 3).

Table 2-9 shows the "old" address (maximum 16 RTDs) and its corresponding "new" address (maximum 32 RTDs).

Note:

If you upgrade an existing configuration from maximum 16 to maximum 32 RTDs, you have to change the addresses in your CONFIG deck on your RTD statements, your CLINK statements, or both.

Table 2-9 RTD/CLINK Addresses - Maximum 32 RTDs

Cluster Number	Interface	RTD/CLINK	Old Address (Maximum 16 RTDs)	New Address (Maximum 32 RTDs)
0	A	0	0A	0A:0
0	A	1	0B	0A:1
0	A	2	-	0A:2
0	A	3	-	0A:3
0	C	0	0C	0C:0
0	C	1	0D	0C:1
0	C	2	-	0C:2
0	C	3	-	0C:3
0	E	0	0E	0E:0
0	E	1	0F	0E:1
0	E	2	-	0E:2
0	E	3	-	0E:3
0	G	0	0G	0G:0
0	G	1	0H	0G:1
0	G	2	-	0G:2
0	G	3	-	0G:3
0	I	0	0I	0I:0
0	I	1	0J	0I:1
0	I	2	-	0I:2
0	I	3	-	0I:3
0	K	0	0K	0K:0
0	K	1	0L	0K:1
0	K	2	-	0K:2
0	K	3	-	0K:3
0	M	0	0M	0M:0
0	M	1	0N	0M:1
0	M	2	-	0M:2
0	M	3	-	0M:3
0	O	0	0O	0O:0
0	O	1	0P	0O:1
0	O	2	-	0O:2
0	O	3	-	0O:3
1	A	0	1A	1A:0
1	A	1	1B	1A:1
1	A	2	-	1A:2
1	A	3	-	1A:3
1	C	0	1C	1C:0
1	C	1	1D	1C:1
1	C	2	-	1C:2
1	C	3	-	1C:3
1	E	0	1E	1E:0
1	E	1	1F	1E:1
1	E	2	-	1E:2
1	E	3	-	1E:3
1	G	0	1G	1G:0
1	G	1	1H	1G:1
1	G	2	-	1G:2
1	G	3	-	1G:3
1	I	0	1I	1I:0
1	I	1	1J	1I:1
1	I	2	-	1I:2
1	I	3	-	1I:3
1	K	0	1K	1K:0
1	K	1	1L	1K:1
1	K	2	-	1K:2
1	K	3	-	1K:3
1	M	0	1M	1M:0
1	M	1	1N	1M:1
1	M	2	-	1M:2
1	M	3	-	1M:3
1	O	0	1O	1O:0
1	O	1	1P	1O:1
1	O	2	-	1O:2
1	O	3	-	1O:3

General VTV Policies

The following sections describe these VTV policies, roughly in order of importance:

• "Maximum VTVs per MVC." Take the default, or see the discussion about high-capacity media.

• "Hosts Disabled from Migration, Consolidation, and Export by VTV or Management Class." If you do not want a host to do these things, you can explicitly turn them off. The default is not to disable any hosts.

• "Recall VTVs with Read Data Checks." The default is to recall VTVs with Read Data Checks. If this does not work for you, you can turn it off either globally or per specific operation.

• "Early Time to First Byte (ETTFB)." ETTFB (also known as the concurrent tape recall/mount feature) allows host applications to read data while VTVs are being recalled from RTDs.

• "VTV VOLSAFE Policy," which allows you to set the VTSS-resident VTV write policy.

Maximum VTVs per MVC

Table 2-10 Maximum VTVs per MVC

Policy:	Values:	Default:	Command to Set Policy:
Specifies the maximum number of VTVs that can be migrated to a single MVC.	4 to 32000 for a D, E or F level CDS. 4 to 65000 for a G level or higher CDS.	32000 for a D, E or F level CDS. 65000 for a G level or higher CDS.	CONFIG GLOBAL MAXVTV parameter

Usage Notes

• This policy applies to all MVCs and, at the time you set the policy, applies only to future migrations. That is, it will not lower the number of VTVs already migrated to an MVC. If the policy is not specified, the default is as shown in Table 2-10 unless the available MVC space is less than any remaining current VTSS resident VTV.

• Generally, use the default to allow VSM to automatically manage VTV stacking. However, with high-capacity media (for example, in a VSM system where all MVCs are type STK2P), specifying a value lower than the maximum may improve recall performance in some situations. Note, however, that a very low value can reduce that percentage of usable MVC space. If the maximum VTVs per MVC is exceeded, then usable space is reported as 0%.

• For more information about CDS levels, see "CDS VTCS Level Requirements."

Hosts Disabled from Migration, Consolidation, and Export by VTV or Management Class

Table 2-11 Hosts Disabled from Migration, Consolidation, or Export by VTV or MGMTclas

Policy:	Values:	Default:	Command to Set Policy:
Specifies that a host cannot initiate automatic and demand migration and consolidation processing, or export by VTV or Management Class.	NOMIGRAT, if not specified, migration, etc., is not disabled .	Do not disable	CONFIG HOST

Usage Notes

• Specifying NOMIGRAT also causes NORECLAM to be set; for more information, see "Hosts Disabled from Reclamation."

• MGMTclas IMMEDmig KEEP and IMMEDmig DELETE are mutually exclusive with CONFIG HOST NOMIGRAT. If you specify both, the IMMEDmig value overrides NOMIGRAT (for only those VTVs with the IMMEDmig value), and VTCS does not issue a message about this override.

Recall VTVs with Read Data Checks

Table 2-12 Recall VTVs with Read Data Checks

Policy:	Values:	Default:	Command to Set Policy:
Specifies whether VTCS recalls VTVs with read data checks.	YES - Recall VTVs with Read Data Checks.NO - Do not recall VTVs with Read Data Checks.	NO	CONsolid RECALWER EEXPORT RECALWER MVCDRAIN RECALWER RECALL RECALWER

Usage Notes

• The global default is RECALWER=NO, and cannot be overridden at the global level. It can be overridden by specifying RECALWER=YES at the command level as described in Table 2-12.

• During MVC reclaims, VTCS will never recall VTVs with read data checks, regardless of the RECALWER setting.

• If a recall fails with a data check, and RECALWER=YES, VTCS attempts to recover the data, which includes both swapping to alternative MVC volumes (if more than one copy of the VTV was migrated) and swapping to other RTDs. If all attempts to recover the data has failed, VTCS has two options:

  • Recall the VTV with the data check. This means that when the application attempts to read the data, a data check is presented to the application and the application can take what ever recovery steps are required (for example, try to operate just like a real tape).

  • Fail the recall, in which case the VTV will not mount and the application will time out.

Early Time to First Byte (ETTFB)

Table 2-13 ETTFB Policy

Policy:	Values:	Default:	Command to Set Policy:
Specifies whether VTCS recalls VTVs with read data checks.	YES, NO	NO	CONFIG GLOBAL FASTRECL

Usage Notes

ETTFB (also known as the concurrent tape recall/mount feature) allows host applications to read data while VTVs are being recalled. ETTFB applies to recall from MVCs and from VMVCs (VLE 1.2 and above). ETTFB is done by overlapping the VTV recall and mount phases, which allows the application to read the VTV data sooner. If the application attempts to read part of the VTV that has not been recalled, the application's I/O request is blocked until the required VTV data is been recalled.

ETTFB is a good choice for applications that serially access the VTV data. ETTFB is generally not a benefit for those applications that stack multiple files on a single VTV, including HSM and image management applications. In these types of applications, the desired data is usually not at the beginning of the VTV, but rather at some random location in the VTV

CONFIG GLOBAL FASTRECL=YES is the global setting to enable ETTFB, which you can override on a per VTSS basis using the CONFIG VTSS NOERLYMT parameter.

VTVs that have incurred an ETTFB recall error have an error flag set in their VTV record in the CDS. These VTVS are subsequently not selected for ETTFB. If you want to reset the error flag, do the following:

1. Enter a VTVMAINT SCRATCH(ON) command for the VTV.

2. Migrate the VTV to a new MVC copy.

3. Import the VTV.

4. Create a new version of the VTV.

5. Scratch the VTV.

VTV VOLSAFE Policy

This policy specifies the VTV VOLSAFE policy.

Table 2-14 Stacked Migrates Policy

Policy:	Values:	Default:	Command to Set Policy:
Specifies the VTV VOLSAFE policy.	MANY, ONCE	MANY	MGMTclas WRITE parameter

Usage Notes

The MGMTclas WRITE parameter specifies the VTSS-resident VTV VOLSAFE policy as follows:

MANY

the default, specifies no VOLSAFE write protection.

ONCE

after the VTV is non-scratch, it cannot be overwritten or appended while it is mounted on a VTD.

Note:

• Migrated VTVs no longer have VOLSAFE protection unless you migrate them to VOLSAFE MVC media.

• Scratch processing generates an explicit security call to check the user's authority when attempting to scratch a VOLSAFE protected VTV. RACF ALTER authorization must be established for any userid used to scratch VOLSAFE protected volumes.

  You can now use HSC HSC Volume Access User Exit (SLSUX14) to prevent a Security Access Facility (such as RACF) from putting volumes into scratch status. For more information, refer to the publications ELS Programming Reference and Managing HSC and VTCS.

VTV Migration Policies

The following sections describe VTV Migration policies, and end with a comprehensive example in "Putting It All Together: VTV Migration Control Example for an Enterprise."

• "Streamed/Stacked Migrates." Enabling stacked migrates can improve migration performance, and it is a CONFIG GLOBAL setting.

• "Minimum Residency Time before Automatic Migration Candidacy." A method to influence VTV availability. You can also influence how quickly VTVs are automigrated after the interval expires per "Maximum Residency Interval before Deletion."

• "Maximum Residency Interval before Deletion." The opposite of the above bullet, a method to quickly safeguard your data and conserve VTSS space.

• "Immediate Migration Delay Interval." This specifies the amount of time in minutes to wait until immediate migrate selects VTVs for migration.

• "Maximum and Minimum Concurrent Migration Tasks." Something to pay attention to because a thoughtful setting can help optimize your VSM resources. Again, you have a global setting that you can override with the SET MIGOPT command.

• "Prioritizing Automatic and Immediate Migration Workloads." A carefully planned setting can help optimize your VSM resources. Higher values may speed up migration, lower values optimize cartridge use for volumes being sent offsite.

• "Controlling Migration Workloads," which is the inverse of the above bullet, and applies to the full range of migration types.

• "Conditionally Change Migration Preferencing/Depreferencing."

• "Dependent Immediate Migration," which you can use to control VLE to VLE copy. For more information, refer to Configuring the Host Software for VLE.

Tip: You can use Display MIGrate to display migration status.

Streamed/Stacked Migrates

This policy enables streamed/stacked migrates.

Table 2-15 Stacked Migrates Policy

Policy:	Values:	Default:	Command to Set Policy:
Specifies whether streamed/stacked migrates is enabled.	STREAM, STACKED NO	NO	CONFIG GLOBAL FASTMIGR

Usage Notes

Enabling the stacked migrates feature can improve migration performance as follows:

STREAM

The streaming method is used for migrations. VTCS monitors the responses from the RTD and uses them to decide as to when a VTV has become migrated. Full advantage is made of the buffer within the RTD to improve the throughput when performing migration.

This option also implies the use of the STACKED feature as well.

STACKED

The stacked method is used for migrations. VTCS maintains a small queue of requests to the VTSS. Advantage will be taken of the various buffers in the VTSS and RTD to improve the throughput when performing a migration. For backward compatibility, the value YES is also taken to mean STACKED.

No

Disable stacked migrates (the default).

Note:

FASTMIGR=STREAM | STACKED has the following prerequisites:

• FASTMIGR=STACKED. VSM4/VSM5 microcode D02.05.00.00 or higher. If this level of microcode is not installed on all VTSSs in the configuration, Stacked Migration will be limited to the VTSSs that have it installed.

• FASTMIGR=STREAM. VSM4/VSM5 microcode D02.15.xx.00 or higher. If this level of microcode is not installed on all VTSSs in the configuration, Streamed Migration will be limited to the VTSSs that have it installed.

• ELS 7.0 or higher with PTFs.�

• CDS level G or higher.

• FICON ports for FICON RTDs and CLINKs.

For the Stacked Migration feature to be enabled, all hosts must be running the prerequisites, otherwise:

• If a host is active that does not support or tolerate stacked migrates, this will cause the CONFIG utility to return an error.

• If a host is started and does not tolerate or support this feature, the host will shut down.

Minimum Residency Time before Automatic Migration Candidacy

Table 2-16 Minimum VTV Residency Interval

Policy:	Values:	Default:	Command to Set Policy:
By default, VSM selects VTVs for automatic migration based on size and usage. You can, however, specify a VTV's minimum residency time before automatic migration candidacy.	1 - 9999	None	MGMTCLAS RESTIME

Usage Notes

• The RESTIME value in a VTV's Management Class sets the recommended interval that the VTV remains VTSS-resident from the time that instance of the VTV is created, which is a method to influence VTV availability. A new instance of the VTV is created whenever the VTV is updated. At automigration time, the creation date and time of the VTV instance plus the RESTIME value is compared to the TOD clock to determine if the VTV is an automatic migration candidate.

• Note the following:

  • A VTV's Management Class (and attributes, such as RESTIME) is set after a scratch mount or optionally after a specific mount if VTVattr = ALLmount.

  • The RESTIME value is only a recommendation. VTCS can migrate a VTV before its residency interval expires if the DBU has not reached the LAMT or the specified migrate-to-threshold value and no VTVs have expired their residency intervals.

  • You can do a demand migrate of a VTV and delete it from the VTSS even if its residency interval has not expired.

The following scenario shows how the RESTIME parameter works:

1. You create Management Class with a RESTIME of 10 hours.

2. A job requests a scratch mount for the Management Class you created in Step 1 VTCS selects and mounts a scratch VTV. The VTV is updated, so at dismount time, its RESTIME value is set to 10 hours (which began when VTCS mounted the VTV).

3. VTCS migrates the VTV after 3 hours, then recalls the VTV 2 hours later for a read. The RESTIME value is not reset, and there are now 5 hours of residency remaining

4. Two hours later, a job updates the VTV, which was 7 hours old. The update creates a new instance of the VTV and the residency interval will restart from the time the VTV was mounted for update.

5. Twenty four hours later, VTCS migrates the VTV, then recalls it 2 days later for a read. VTCS does not create a new instance of the VTV because it is not updated. The residency interval has expired and the VTV is therefore an automatic migration candidate based only on least-recently-used/size criteria.

6. A week later, the VTV is scratched. VTCS eventually selects and mounts the VTV to satisfy a scratch mount request. If the VTV is updated, its residency interval is set to the RESTIME value of the Management Class being used.

Maximum Residency Interval before Deletion

Table 2-17 Maximum Residency Interval before Deletion

Policy:	Values:	Default:	Command to Set Policy:
Specifies the maximum residency interval for migrated VTVs before deletion from the VTSS.	0 - 9999 hours	9999	MGMTCLAS DISCARD

Usage Notes

DISCARD lets you improve VTSS buffer management by requesting that VTVs that will not be used after a known time interval are preferenced for auto migration. DISCARD applies to automatic and immediate migration requests as follows:

• At the start of auto migration, VTVs are preferenced for deletion from the VTSS if the DISCARD value is expired and all required migrated copies exist on MVCs. If the DISCARD value is not expired, the VTV is treated the same as a VTV that does not have a DISCARD value assigned.

• For immediate migrate requests, whether a VTV is deleted is based on comparisons of the IMMDELAY and DISCARD times when the VTV is initially placed on the immediate or delayed migration queues. For example, if a class of data is created and referenced immediately and you set both IMMDELAY and DISCARD to 2 hours, the VTVs are immediate migrated and deleted from the VTSS after 2 hours.

• At the start of auto migration, DISCARD is ignored if RESTIME has not expired. If RESTIME has expired, then DISCARD is honored.

Immediate Migration Delay Interval

Table 2-18 Immediate Migration Delay Interval

Policy:	Values:	Default:	Command to Set Policy:
Specifies the immediate migration delay time in minutes.	0 to 9999	9999	MGMTCLAS IMMDELAY, MIGRVTV IMMDELAY

Usage Notes

• IMMDELAY lets you control the interval when immediate migration is done. For example, you may want some copies of a VTV migrated immediately while other copies are migrated at a later time, such as when the VTV meets the criteria for auto migration. The IMMDELAY parameter specifies the immediate migration delay time, which is the time in minutes to wait until immediate migrate selects VTVs for migration. Higher values preference VTV residency, which allows VTVs used in multi-step jobs to remain resident so that the jobs can complete before the VTVs are processed for migration. A value of zero equals migrate immediate.

  A default strategy is to consider IMMDELAY as a switch:

  • A value of 0 means migrate this VTV copy as quickly as possible.

  • A value of 9999 indicates no immediate migrate (the default) and indicates that this VTV copy is migrated only when selected for auto migration.

  Oracle recommends that you do not use any other values until you evaluate using IMMDELAY as a switch. Then you might want to specify some other values to ”spread out” your migration activity.

• If the VTV requires replication, a value of 0 (immediate migrate) will be assigned. This can be overridden by MGMTCLAS or MIGRVTV IMMDELAY settings.

Maximum and Minimum Concurrent Migration Tasks

Table 2-19 Maximum and Minimum Concurrent Migration Tasks

Policy:	Values:	Default:	Command to Set Policy:
Specifies the maximum and minimum number of concurrent automatic migration, immediate migration, and migrate-to-threshold tasks for each VTSS.	MAXMIG - 1 to the number of RTDs connected to the VTSS. See "Maximum RTDs per VTSS" for more information. MINMIG - 1 to the MAXMIG setting.	MAXMIG - Half the number of VTDs connected to the VTSS. MINMIG - Default is 1.	MAXMIG - CONFIG VTSS MINMIG or SET MIGOPT MINMIG - CONFIG VTSS MINMIG or SET MIGOPT

Usage Notes

• Use these parameters to balance migration tasks with other tasks (such as recall and reclaim) for the RTDs you have defined for each VTSS.

• In some situations, VTCS may not be able to activate all the migration tasks specified by the MAXMIG parameter. For example:

  • The VSM-wide RTD configuration consists of four 9840 and four 9490 transports.

  • No Storage Classes with STK1R as the primary media have been defined.

  • There is sufficient MVC media for the 9490 transports.

  In this configuration, because only the 9490 media is used, only a maximum of four migration tasks are activated using the 9490 RTDs.

• Similarly, there are circumstances when VTCS will start less than the number of migration tasks specified by the MINMIG parameter. For example:

  • The configuration consists of a single VTSS with 4 RTDs in ACS 0 and 4 RTDs in ACS 1. All RTD device types are identical.

  • MINMIG and MAXMIG are both set to 8.

  • Two Storage Classes are defined, which point, respectively, to ACS 0 and ACS 1.

  In this configuration, if there are migrates queued for both Storage Classes, then VTCS will start 8 requests. If however, there are only migrations queued for one Storage Class, then VTCS will not start 8 requests because the workload can only be serviced by one Storage Class and this class can only run on 4 RTDs.

• Finally, also note that when you reset the MINMIG and/or MAXMIG values, the actual number of migration tasks may not be immediately affected because of the way that VTCS manages migration tasks.

Tip: You can use Display MIGrate to display migration status.

Prioritizing Automatic and Immediate Migration Workloads

Table 2-20 Prioritizing Automatic and Immediate Migration Workloads

Policy:	Values:	Default:	Command to Set Policy:
Prioritizes Automatic and Immediate Migration Workloads	0-99	0	MIGRSEL SCHPREF

Usage Notes

In general, MIGRSEL SCHPREF provides finer control over how Storage Classes are treated for migration. Using the MIGPOL parameter, a Management Class can request that multiple VTV copies are migrated to multiple Storage Class destinations. By default, all migrated copies are treated equally. With MIGRSEL SCHPREF, however, you can request that VTCS preferences one or more Storage Classes and the accompanying migrations.

For example, a Management Class requests two MVC copies, where one copy is business critical (perhaps for DR purposes) and the other is not. In this case, you can assign a higher preference to your business critical copy. This preferencing requests that more resources (RTDs/MVCs) are used to service the business critical copy.

MIGRSEL SCHPREF is the tool to preference Storage Classes and their accompanying migrations and MIGRSEL SCHPREF also provides the ability to set a scheduling preference for a narrow and specific set of conditions. For example, if you are migrating on a specific host from a specific VTSS and your immediate wait time has reached a specified threshold, you can then apply the specified preference value.

With that framework in mind, use MIGRSEL SCHPREF as follows:

• Use MIGRSEL SCHPREF to preference automatic and immediate migration per Storage Class. Higher values can produce quicker migration times but may not optimize MVC usage. Lower values may produce slower migration times but may optimize MVC usage.

• MIGRSEL SCHPREF allows you to specify the VTSS and host to which the preferencing applies.

• You can also specify MIGRSEL IMMWAIT, which specifies the age of the queued migrate request in minutes that the MIGRSEL rule applies to. Valid values are 0-999, the default is 999. The search criteria is considered true if the IMMWAIT value is greater than or equal to the search value.

• The MIGRSEL SCHPREF setting may be affected by the number of RTDs available, the SCHLIMIT setting, and the GLOBAL MAXMIG parameter for the VTSS.

Controlling Migration Workloads

Table 2-21 Controlling Migration Workloads

Policy:	Values:	Default:	Command to Set Policy:
Controls migration workloads.	0-99	99 (no limit up to the VTSS MAXMIG value)	MIGRSEL SCHLIMIT

Usage Notes

MIGRSEL SCHLIMIT, like MIGRSEL SCHPREF, provides finer control over how Storage Classes are treated for migration but in the opposite direction. That is, MIGRSEL SCHLIMIT, applies limits on migration resources (RTDs/MVCs) per Storage Class, and you can do so on a VTSS and/or host basis. Use MIGRSEL SCHLIMIT as follows:

• Use MIGRSEL SCHLIMIT to depreference migration per Storage Class. Lower values depreference migration, and you can specify automatic, immediate, demand, and reclaim migrates. Lower values can do the following:

  • Optimize MVC usage. You can use this strategy where you want to limit the number of MVCs used. Example: a workload migrated to a Storage Class that is subsequently used for offsite vaulting.

  • Preference migration to other Storage Classes.

  • Restricts migration concurrency to better use MVCs.

  • Limits migration to keep RTDs available for auto recalls.

  • Reduce MVC swapping when workloads change.

• MIGRSEL SCHLIMIT allows you to specify the VTSS and host to which the preferencing applies.

• For auto and immediate migration processing, MIGRSEL SCHLIMIT depreferences migration for the VTSS to Storage Class relationship. This comparison is not global and only effects requests driven by the individual VTCS host.

• For demand migration requests, MIGRSEL SCHLIMIT it will cause the request to be held if the scheduling of it would cause the number of globally active migration requests on the VTSS that satisfy the same FUNCTION and STORCLAS selection criteria to be exceeded. The migration requests will be released and a MVC picked once the constraint subsides.

Conditionally Change Migration Preferencing/Depreferencing

Table 2-22 Conditionally Change Migration Preferencing/Depreferencing

Policy:	Values:	Default:	Command to Set Policy:
Conditionally changes migration preferencing/depreferencing.	0-999 minutes	999	MIGRSEL IMMWAIT

Usage Notes

In the world of VTV migration, things change. VTCS puts VTV migration candidates on migration wait queues, where they wait until resources are available. Some days, VTVs are on a wait queue longer than others, so VTVs are not migrated in a timely fashion. You can use MIGRSEL IMMWAIT to conditionally manage variations in wait queue times. MIGRSEL IMMWAIT essentially sets a wait time limit, and if the wait time is less than or equal to this limit, VTCS starts the condition specified on the MIGRSEL statement to which the IMMWAIT value applies.

For example, if you have a "local" Storage Class that you want to limit/depreference the immediate migration resources:

MIGRSEL STOR(LOCAL)FUNCTION(IMMED)SCHLIMIT(1)

You know from consulting the VTV dashboard that the normal immediate queue wait time for this Storage Class is 15 minutes. Any more than 15 minutes and your immediate migrations are no longer immediate. So to reduce some of the limiting, do the following:

MIGRSEL STOR(LOCAL)FUNCTION(IMMED)IMMWAIT(15) SCHLIMIT(2)

Again, more granularity of control: set a basic preferencing/depreferencing, and automatically adjust it based on changes in queue wait times.

Dependent Immediate Migration

Table 2-23 Dependent Immediate Migration

Policy:	Values:	Default:	Command to Set Policy:
Specifies dependent immediate migration policy.	INDEPEND, INITIAL, SUBSEQNT(timeout)	INDEPEND	MIGRVTV

Usage Notes

These MIGRVTV parameters Specifies dependent immediate migration policy as follows:

INDEPEND

Affected VTVs are independent of any other VTV migrate instance. This is the default and applies to any migrates that do not match a MIGRVTV rule or any rule without an INITIAL or SUBSEQNT parameter.

INITIAL

Affected VTV migrates are scheduled and performed before any migrate instances that match to a rule with the SUBSEQNT parameter.

SUBSEQNT(timeout)

Affected VTV migrates are scheduled and performed after any migrate instances that match to a rule with the INITIAL parameter. timeout specifies the time in minutes after which the rule expires. timeout is in addition to any IMMDELAY applied to the INITIAL migrate instances.

You can use Dependent Immediate Migration to control VLE to VLE copy. For more information, refer to Configuring the Host Software for VLE.

Putting It All Together: VTV Migration Control Example for an Enterprise

With VTV migration control, you have gained finer control over:

• VTSS space management.

• Speedy migration of critical data (for example, to MVCs destined for a remote ACS).

• MVC usage (for example, to ensure maximum space usage for MVCs destined for offsite vaulting).

The good part is that you can do all of the above concurrently. For example, if you want two VTV copies, one local and one remote, you can preference migration for the "remote" Storage Class and specify that VTVs are deleted from the VTSS ASAP after migration completes. Similarly, you can depreference migration for the "local" Storage Class and specify relatively long VTSS residency so that VTV availability is enhanced.

To demonstrate Enhanced Migration Control for an enterprise that has four typical classes of data, and name their corresponding Storage Classes accordingly:

• The REMOTE Storage Class is for MVCs going to a remote ACS. They are the primary backup for critical data so they require high migration preferencing to ensure speedy migration as described in "Enabling the Remote and Local ACS Migrations."

• The LOCAL Storage Class is for the local VTV copy of critical data. As described above, depreference migration to these MVCs (but optimize data availability) as shown in "Enabling the Remote and Local ACS Migrations."

• The LTRVLT1 Storage Class is for MVCs destined for long term retention in an offsite vaulting. You can also do vaulting for DR, and you can do both of these (and manage "floor" volumes) with the ELS Vault Solution. For more information on this scenario, refer to Managing HSC and VTCS. In "Migration Policies for a Vault Solution," you are just going to show the code to achieve the above business objectives for vaulting volumes.

• The OTHER Storage Class is for temporary data sets and other things you need to safeguard, but as cheaply as possible. You want this data out of the VTSS buffer as quickly as possible, which you do using DISCARD and DELSCR as described in "Enabling the "Other Data" Migrations."

Enabling the Remote and Local ACS Migrations

In this scenario, the overall business goals are optimizing VTSS buffer use and ensuring speedy migration of critical data, while maintaining data availability. There are two MVC copies of each VTV, which are represented by these two Storage Classes:

• The REMOTE Storage Class is for MVCs going to a remote ACS. They are the primary backup for critical data so they require high migration preferencing to ensure speedy migration. The examples that follow use T10K media for the REMOTE Storage Class, so you want to optimize media use.

• The LOCAL Storage Class is for the local VTV copy of critical data. The goal here is to depreference migration to these MVCs but to optimize data availability, which includes specifying T98490D media.

And, of course, use VTSS space as efficiently as possible.

To (efficiently) enable both remote and local ACS migrations:

1. Create the LOCAL and REMOTE Storage Classes with the appropriate media and ACS values:

   STOR NAME(LOCAL) ACS(00)MEDIA(STK1R)
   STOR NAME(REMOTE) ACS(01) MEDIA(T1B000E1)
   

2. Create MIGRSEL statements corresponding to the LOCAL and REMOTE Storage Classes:

   MIGRSEL STOR(LOCAL)FUNCTION(IMMED)SCHLIMIT(1)
   MIGRSEL STOR(REMOTE) FUNCTION(IMMED)SCHPREF(9)
   

   In this example:

   • The LOCAL Storage Class reduces immediate migration tasks severely, because auto migration will get the data migrated soon enough.

   • The REMOTE Storage Class gives immediate migration tasks the highest priority possible, because you want these VTVs on MVC space ASAP.

   This step sets the priorities for the immediate migrate speed. Data availability/VTSS buffer management is addressed in the next step.

3. Create MIGRVTV statements corresponding to the LOCAL and REMOTE Storage Classes:

   MIGRVTV STOR(LOCAL)IMMDELAY(9999)
   MIGRVTV STOR(REMOTE)IMMDELAY(0) 
   

   These statements used the "switch" philosophy for IMMDELAY:

   • REMOTE is set to 0, so migrate VTV copies to it ASAP.

   • LOCAL is set to 9999, so migrate VTV copies to it only when you select the VTV for auto-migration.

   As you can see, you have gained more and more granularity, finer and finer control, which continues in the next step.

4. Create a MGMTCLAS statement that points to the LOCAL and REMOTE Storage Classes:

   MGMT NAME(COMPLY) MIGPOL(LOCAL,REMOTE)DISCARD(0)DELSCR(YES)
   

   The above example provides this additional fine tuning for both Storage Classes:

   • After the VTVs are successfully immediately migrated, they are not likely to be re-referenced again, so delete them from the VTSS to optimize VTSS buffer space.

   • If the VTV is scratched, and you run LCM (best practices) scratch synchronization, delete the VTV from the VTSS, which is more good VTSS buffer management.

5. Create and activate an SMC POLICY statement to point to the COMPLY Management Class and specify virtual media:

   POLICY NAME(CPLY) MEDIA(VIRTUAL) MGMT(COMPLY)
   

6. Create a TAPEREQ statement that points to the CPLY Policy:

   TAPEREQ DSN(LOVEDONES.**) POLICY(CPLY) 
   

7. Activate the new TAPEREQ set by issuing the SMC TREQDEF command.

Migration Policies for a Vault Solution

As stated in "Putting It All Together: VTV Migration Control Example for an Enterprise," you can do vaulting for a variety of reasons and using a range of different methods. For more information on the ELS Vault Solution, refer to Managing HSC and VTCS. The following shows the code for the migration policies that control the data management, using a Long Term Vault (LTR) vault as an example.

To implement migration policies for vaulting:

1. Create the LTRVLT Storage Class. For example:

   STOR NAME (LTRVLT1) ACS(00) MEDIA(STK2PB) 
   

2. Create a MIGRSEL statement corresponding to the DRLOC and DRVLT Storage Classes:

   MIGRSEL STOR(LTRVLT1) FUNCTION(IMMED)SCHPREF(9)
   

   So for the LTRVLT1 Storage Class, immediate migration tasks are the highest priority possible, because you want this data protected on an MVC as soon as possible.

3. Create a MIGRVTV statement corresponding to the LTRVLT1 Storage Class:

   MIGRVTV STOR(LTRVLT1)IMMDELAY(0) 
   

   LTRVLT1 IMMDELAY is set to 0, so migrate VTV copies to it as soon as possible.

4. Create a Management Class that points to the Storage Class in Step 1. For example:

   MGMT NAME(LTRV) DISCARD(0) DELSCR(YES) MIGPOL(LTRVLT1)
   

   This Management Class says:

   • After the VTVs are successfully immediately migrated, they are not likely to be referenced again, so delete them from the VTSS to optimize VTSS buffer space.

   • If the VTV is scratched, and you run LCM (best practice) scratch synchronization, delete the VTV from the VTSS. This is more good VTSS buffer management.

5. Use the SMC POLICY command to point to the Management Class in Step 4. For example:

   POLICY NAME(VLTRV1) MGMT(LTRV1)
   

6. Create a TAPEREQ statement to route the LTR data to VSM and assign the corresponding Policy/Management Class to the data. For example:

   TAPEREQ DSN(COMPLY*) POLICY(VLTRV1) 
   

7. Activate the new TAPEREQ set by issuing the SMC TREQDEF command.

Enabling the "Other Data" Migrations

The OTHER Storage Class is for temporary data sets and other things needed to safeguard, but as cheaply as possible. You want this data out of the VTSS buffer as quickly as possible, which you do using DISCARD and DELSCR.

To enable the "other data" migrations:

1. Create the OTHER Storage Class:

   STOR NAME(OTHER) ACS(00)MEDIA(STK1R)
   

   So OTHER goes to the local ACS only, 9840D media in case you need to it back up quickly. For "Other Data" Automigration runs as is, and do not worry about using MIGRSEL/MIGRVTV to fine tune things.

2. Create a MGMTCLAS statement that points to the OTHER Storage Class:

   MGMT NAME(TEMPS) MIGPOL(OTHER)DISCARD(0)DELSCR(YES)
   

   This statement specifies the following:

   • After the VTVs are successfully immediately migrated, delete them from the VTSS to optimize VTSS buffer space.

   • If the VTV is scratched, and you run LCM (best practices) scratch synchronization, delete the VTV from the VTSS. This is more good VTSS buffer management.

3. Create and activate an SMC POLICY statement to point to the TEMPS Management Class and specify virtual media:

   POLICY NAME(TDATA) MEDIA(VIRTUAL) MGMT(TEMPS)
   

4. Create a TAPEREQ statement that points to the CPLY Policy:

   TAPEREQ DSN(TEMP*.**) POLICY(TDATA)
   

5. Activate the new TAPEREQ set by issuing the SMC TREQDEF command.

VTV Replication Policies

VTSS CLINKs are capable of replication, which is copying VTVs from one VTSS to another. The following sections describe VTSS replication policies.

• "VTCS Replication - Always or Changed VTV Only." Here, the concept is simple but read the section so that you understand how ”changed VTVs” are defined.

• "VTCS Replication - Synchronous or Asynchronous." You have another choice with replication (assuming that you have satisfied all the requirements), which is synchronous or asynchronous processing.

VTCS Replication - Always or Changed VTV Only

Table 2-24 VTV Replication - Always or Changed VTV Only

Policy:	Values:	Default:	Command to Set Policy:
Specifies whether a VTV is always replicated or only when changed.	ALWAYS, CHANGED	ALWAYS	CONFIG GLOBAL REPlicat

Usage Notes

• ALWAYS means the replicate request is added to the VTCS replication queue every time the VTV is dismounted, regardless of whether the VTV was changed while it was mounted (the default).

• CHANGED means the replicate request is added to the VTCS replication queue if the VTV:

  • Was changed while it was mounted or

  • Was only read while mounted but less than the expected number of MVC copies of the VTV exist.

    Note:

    Regardless of the CONFIG GLOBAL REPlicat setting, replication also requires that:

    • The VTV must be dismounted in a VTSS that supports replication and there cannot be an identical copy of the VTV in the other VTSS in the Cluster.

    • In addition to the CONFIG GLOBAL REPlicat value, you must specify REPlicat(YES) on a VTV's Management Class for replication to occur.

VTCS Replication - Synchronous or Asynchronous

Table 2-25 VTV Replication - Synchronous or Asynchronous

Policy:	Values:	Default:	Command to Set Policy:
Specifies whether synchronous replication is enabled.	YES, NO	NO	CONFIG GLOBAL SYNCHREP

Usage Notes

YES means that synchronous replication is enabled, but make sure you have all the requirements lined up as described in Creating ELS Disaster Recovery Solutions.

Note:

• Regardless of the CONFIG GLOBAL SYNCHREP setting, replication also requires that you must specify REPlicat(YES) on a VTV's Management Class for replication to occur.

• Synchronous replication does incur a performance penalty. That is, when synchronous replication is specified, the replication of the new or modified VTV to the other VTSS is made prior to the completion of the rewind/unload of the original VTV. When the virtual volume completes close processing, VTSS has completed performing the replication of the volume. Synchronous replication ensures that, under normal conditions, two identical copies of a virtual volume exist, as soon as the rewind/unload command has completed. You should consider using synchronous replication if it is mandatory for your operation to have the highest level of protection for your tape data. With synchronous replication in an unconstrained environment, the time required to replicate a virtual volume can significantly delay the completion of the rewind/unload command. This time will increase in a constrained environment and for larger VTV sizes.

  If a synchronous replication cannot be completed immediately (likely caused by the failure of the connections between the VTSSs), the synchronous replications will operate as asynchronous replications until the failure has been corrected. If a synchronous replication is changed to an asynchronous replication, the system is notified with a warning message.

MVC Policies

The following sections describe these MVC policies. It is usually a good idea to supplement automatic reclamation with demand reclamation as described in Managing HSC and VTCS.

• "Standard Reclaim Threshold - Determines MVC Eligibility for Reclamation (Requires Recall/Remigration)." It makes sense that you want to maximize results when you do a standard reclaim, because it costs you resources that you could be otherwise using for migrates and recalls. This is the threshold value you can use to specify how fragmented an MVC must be to make it a reclaim candidate.

• "Dynamic Reclaim Threshold - No MVC Mount or VTV Recall/Remigration Occurs." For T10000B and above media, dynamic reclaim, which requires no recalls or migrates, optimizes reclamation for capacity-centric media.

  Note that the reclaim thresholds only dictate when an MVC becomes a reclaim candidate. They do not start automatic reclamation; see the next two bullets.

• "Dynamic Reclaim - Specifying VTV Data Movement." The RECLaim MOVEDATA parameter can be used to limit VTV data movement and to free up low-use partitions on an Automatically Linked Partition (ALP) MVC.

  Note:

  Reclamation turns fragmented MVC space (space that contains non-current VTVs) into usable space (writable MVC space). MVC reports and Display MVCpool show the percentages of MVC space that is fragmented, used (space that contains current VTVs), available, and usable. Note that usable space may be zero even if there is still space physically available. For example, if the maximum VTVs per MVC is exceeded, then usable space is reported as 0%. You set maximum VTVs per MVC. Similarly, if a data check error has been reported against an MVC, VTCS will not use this MVC for output and usable space is reported as 0%.

• "VLE Reclaim Threshold - Determines VMVC Eligibility for Reclamation." There is a reclaim policy for VMVCs.

• "Free MVCs Threshold - Starts Automatic Space Reclamation" and "Eligible/Total MVCs Threshold - Starts Automatic Space Reclamation."

  There are two different triggers that start automatic reclamation. More fine tuning, more granularity. These triggers supplement rather than compete with each other. If either you run low on Free MVCs or your ratio of eligible to total MVCs gets too low, automatic reclamation starts.

• "Maximum MVCs Processed Per Reclaim." VTCS reclaims MVCs one at a time. You can, however, specify the maximum number you want to reclaim in one run, either automatic or demand. You can specify that when reclamation starts, run it to reclaim this number of MVCs, because that is the value that allows you to have sufficient free MVCs.

• "Maximum MVCs Concurrently Processed for Reclamation and Drain." A reasonable question is, what is the difference between this and maximum MVCs processed per reclaim, especially since you can only reclaim one MVC at a time? It turns out that reclaim and drain are separate but related processes that can be processing multiple MVCs, and you get to say how many.

• "Hosts Disabled from Reclamation." If you do not want a host to initiate reclamation, you can explicitly turn it off. The default is not to disable any hosts, so if this is not an issue, do not worry about it.

• "MVC Retain Interval." The idea is pretty simple: if you think you are going to write more data to an MVC once it is mounted and initially written to, you can specify a value that keeps it available. A similar control is the MVC mount timeout interval, see "MVC Mount Timeout Interval."

• "Non-Library Resident MVC Policies." The non-library resident MVC policies specify how VTCS processes MVCs that are not in the ACS.

• "MVC Initialization on First Mount." Initializing MVCs before they are used is no longer required, thanks to this global and MVC Pool parameter. You can now specify that the MVC is initialized at first mount.

Standard Reclaim Threshold - Determines MVC Eligibility for Reclamation (Requires Recall/Remigration)

Table 2-26 Standard Reclaim Threshold

Policy:	Values:	Default:	Command to Set Policy:
Specifies the standard reclaim threshold (as a percentage) that determines when an MVC is eligible for demand or automatic reclamation.	4 - 98	40	CONFIG RECLAIM THRESHLD RECLAIM THRESHLD MVCPOOL THRESHP

Usage Notes

• Inevitably, MVCs become separated with gaps where non-current VTVs reside, which is sub-optimal space use. Customers can use the CONFIG utility to set MVC space reclamation parameters, and they also can use the RECLAIM command or utility to adjust these parameters. When MVCs reach specified thresholds, VTCS automatically starts standard space reclamation, reclaiming space one MVC at a time. VSM reclaims space by copying only valid VTVs from the selected MVC to the VTSS, then copying these VTVs back to another MVC with sufficient space. VSM copies only those VTVs placed after the first open space on the MVC, which saves I/O cycles. The space reclamation thus reduces MVC fragmentation and allows the migration to succeed.

  If fragmented space on an MVC exceeds the value specified on THRESHLD, VTCS makes the MVC eligible for reclamation. Regardless of the percentage of fragmented space on an MVC versus this value, however, VTCS also considers where fragmented space occurs. For example, if the first fragmented space is near the end of the MVC, VTCS may process the MVC before an MVC with more total fragmented space.

• You can use Display MVCpool to display the MVCs eligible for reclamation in your MVC pool, as well as information about MVC status and space.

• To optimize recall processing in mixed-media systems, ensure that your MVC pool has at least one media type compatible with each RTD type.

• The MEDIA parameter of the STORclas statement (which defines Storage Classes) specifies a preference list of MVC media types. This list supersedes the default media selection list.

• If the system's MVCs are highly fragmented, a demand standard MVC space reclamation can be scheduled (using RECLAIM) as an off–hours batch job.

• Dynamic reclaim does not apply to T10000D Sport cartridges. Dynamic reclaim requires an H level CDS, VSM5 microcode D02.11.16.00 or later, T10KB firmware 1.41a.209 or later.

• You can specify Dynamic Reclaim policies at the global, system wide level or on a Storage Class and MVC pool level. The global policies are set by the VTCS CONFIG RECLAIM statement:

  • The INPLACE(YES/NO) parameter controls the usage of dynamic reclaim. The INPLACE setting can either be explicitly specified upon the STORCLAS statement or inherited from the RECLAIM statement in the VTCS configuration. The default is INPLACE=NO. The setting that is derived for a Storage Class does not force usage of media formatted in either mode. So it is quite acceptable to use with drives or media that do not support partitioning. Also, any media written in a different mode will continue to be a migration target. This will avoid the need to actively manage the transition when dynamic reclaim is activated. Its effect is to cause new media allocated to the Storage Class to be formatted and written in either standard (INPLACE=NO) or partitioned (INPLACE=YES) mode. The switch can only occur when media is empty.

    If a hard switch-over is required between standard and dynamic reclaim, then a lengthy process is required. Parameters setting (for example, MEDIA on the STORCLAS statement) will need to be used. MVCs will need to be either taken out of the MVC pool or set into a read-only state by using MVCMAINT. Finally, MVCs formatted in the wrong mode would need to be drained. 

  • The INPTHRSH parameter specifies the fragmentation level that makes partitioned MVCs eligible for Dynamic reclaim. When a partitioned MVC's fragmentation falls between the INPTHRSH value and the THRESH value, it first becomes eligible for Dynamic Reclaim. If no space is freed on the initial reclaim attempt, the reclaim will be retried when the fragmentation level has risen significantly. Should the fragmentation level reach the standard THRESHOLD be reached, then a fall-back method of moving VTVs will be performed. This will still be less than for standard format media.  

• The VTCS CONFIG RECLAIM statements provide the global defaults for the system. These can be overridden at the Storage Class and MVCPool level:

  • The STORCLAS INPLACE parameter specifies whether or not Dynamic Reclaim is enabled for this Storage Class. Note that initially, you may want to specify INPLACE(NO) in the VTCS CONFIG RECLAIM statement and INPLACE(YES) for selected Storage Classes so you can evaluate the effects of Dynamic Reclaim. Subsequently, if you decide you want Dynamic Reclaim to apply to all eligible media, you can specify INPLACE(YES) on the VTCS CONFIG RECLAIM statement.

  • The INPTHRSH parameter on the POOLPARM statement can be used to set a Dynamic Reclaim threshold specifically for this set of MVC media. This can be used if you wish to treat some MVCs differently from the VTCS CONFIG RECLAIM defaults.

• Dynamic Reclaim can be disabled either globally at a system wide level or at the Storage Class level:

  • To disable Dynamic reclaim globally specify INPLACE(NO) in the VTCS CONFIG RECLAIM statement and ensure that any Storage Class definition does not override this to YES.

  • To disable Dynamic for one or more Storage Classes change INPLACE to NO in the Storage Class policy statements.

    Note:

    Any MVCs that are currently in use for migration will continue in partitioned format. If you wish to stop active MVCs from further migrates then use the MVCMAINT utility to mark them as read-only. Once the partitioned volumes are empty they will be automatically re-used in non-partitioned mode. An MVC will become empty either when all VTVs have expired or the MVC has been DRAINed.

Dynamic Reclaim Threshold - No MVC Mount or VTV Recall/Remigration Occurs

Table 2-27 Dynamic Reclaim Threshold

Policy:	Values:	Default:	Command to Set Policy:
Specifies if dynamic reclaim is enabled.	YES, NO	No default	CONFIG RECLAIM INPLACE STORCLAS INPLACE
Specifies the dynamic reclaim threshold (as a percentage) that determines when an MVC is eligible for demand or automatic reclamation.	Less than CONFIG RECLAIM THRESHLD and between 3 and 97	Half the CONFIG RECLAIM THRESHLD value (rounded up).	CONFIG RECLAIM INPTHRSHMVCPool INPTHRSHPOOLPARM TYPE(MVC) INPTHRSH

What is Dynamic Reclaim?

As shown in Figure 2-2, with a standard MVC whose fragmentation exceeds the standard reclaim threshold, standard reclaim must recall/remigrate VTVs (V3, V4, and V5, in this example) in order to reclaim MVC space.

Figure 2-2 Standard Reclaim Example

Figure 2-3 shows a blank partitioned MVC with all partitions free.

Figure 2-3 Blank Partitioned MVC

Figure 2-4 shows a partitioned MVC with all partitions full. The VTVs are in light blue, on top, and the partitions are in dark blue, on the bottom.

Figure 2-4 Full Partitioned MVC

Figure 2-5 shows a fragmented partitioned MVC, where VTVs 6 and 14 have expired, which frees partitions 6, 7, 15, and 16. These partitions are "dynamically reclaimed," which means they are now available for migration of new VTVs. For dynamic reclaim, VTCS just updates the CDS to mark the freed partitions as writeable; the MVC is not mounted and no data movement occurs.

Figure 2-5 Dynamically Reclaimed Partitioned MVC

Figure 2-6 shows the dynamically reclaimed MVC shown in Figure 2-5. VTVs 21 and 22 were subsequently migrated to partitions 6 and 7 and 15 and 16 respectively. Note that VTV 21 spans partitions 6 and 7 and VTV 22 spans partitions 15 and 16 because each partition on the MVC is automatically linked to the next partition.

Figure 2-6 Dynamically Reclaimed Partitioned MVC - New Migrations

Usage Notes

• Dynamic reclaim only applies to T10000B and above media (full and full encrypted only) that have been formatted by T10000 drives capable of creating partitions.

• For 32 GB VSM 6 VTVs, eight VTVs can span a partition.

Dynamic Reclaim - Specifying VTV Data Movement

The RECLaim command performs demand MVC space reclamation. Use the MOVEDATA parameter to limit VTV data movement and to free up low-use partitions on an Automatically Linked Partition (ALP) MVC.

Table 2-28 Dynamic Reclaim - Data Movement

Command:	Values:	Default:	Command to Set Policy:
Specifies the extent of VTV data movement that results from an MVC being reclaimed.	Standard, Minimum, None	Standard	RECLaim MOVEDATA

Usage Notes

• To reclaim only your eligible ALP MVCs INPLACE and ensure no data movement occurs for MVCs over the THRESH value, include the parameter MOVEDATA(None) on associated dynamic reclaim commands.

  Figure 2-7 shows an MVC report with three ALP MVCs.

  Figure 2-7 Three ALP MVCs and MOVEDATA(None)

  
  

  When MOVEDATA(NONE) is specified:

  RECLAIM STORCLAS(S0) INPTHRSH(3) THRESHLD(6) MOVEDATA(NONE)
  

  MVC DMV600 contains VTVs with changed MGMTclas definitions specifying different STORclas(es). It is above the INPTHRSH value and below the THRESHLD value. It has empty partitions. It is eligible for INPLACE reclaim.

  MVC DMV601 is above the INPTHRSH value and below the THRESHLD value. It has empty partitions. It is eligible for INPLACE reclaim. There are no VTVs with MGMTclas definitions requiring reconciliation, movement, or other actions.MVC DMV602 is above the THRESHLD value.

  After specifying MOVEDATA(NONE), Figure 2-8 shows the MVC report after reclaim.

  Figure 2-8 MVC Report After MOVEDATA(None) Specified

  
  

  MVC DMV600 contains the same number of VTVs. No data movement has occurred for the VTVs with changed MGMTclas or STORclas definitions. The fragmentation percentage has been reduced because a number of partitions have been freed up by INPLACE.

  MVC DMV601 contains the same number of VTVs. No data movement has occurred, but some space has been reclaimed from empty partitions freed by INPLACE.

  MVC DMV602 contains the same number of VTVs. No data movement has occurred even though the fragmentation was over the THRESHLD value. Some space has been reclaimed from empty partitions with the EOT position reset. However, in this particular test case, due to the layout of data across partitions on the MVC, the %Used and %Frag calculated values have actually increased slightly.

• To reclaim your eligible ALP MVCs INPLACE and free up partitions with free space exceeding the THRESH value, include the parameter MOVEDATA(Minimum) on associated dynamic reclaim commands.

  Figure 2-9 shows an MVC Report with two ALP MVCs.

  Figure 2-9 Two ALP MVCs and MOVEDATA(Minimum)

  
  

  When MOVEDATA(Minimum) is specified:

  RECLAIM STORCLAS(S0) INPTHRSH(5) THRESHLD(90) MOVEDATA(MINIMUM)
  

  MVC DMV600 contains VTVs of varying sizes. It is above the INPTHRSH value and below the THRESHLD value. It does not contain any empty partitions, but it does have some low-use partitions. It is eligible for INPLACE reclaim and some partitions can be expected to be freed by defrag.

  MVC DMV601 contains VTVs of varying sizes. It is above the INPTHRSH value and below the THRESHLD value. It does not have any empty partitions but it does have some low-use partitions. It is eligible for INPLACE reclaim and some partitions can be expected to be freed by defrag.

  After specifying MOVEDATA(Minimum), Figure 2-10 shows the MVC report after reclaim.

  Figure 2-10 MVC Report After MOVEDATA(Minimum) Specified

  
  

  MVC DMV600 has had 9 VTVs moved off it by defrag. The used partition count has gone from 75 to 69, that is, 6 partitions have become free. Some space has been reclaimed from these defragged partitions and the EOT position has been reset. However, in this particular test case, because of the layout of data across partitions on the MVC, the %Used, %Avail and %Frag calculated values have not changed much, even though a number of partitions were freed.

  MVC DMV601 has had 125 VTVs moved off it by defrag. The used partition count has gone from 186 to 61, that is, 125 partitions have become free. A lot of space has been reclaimed from these defragged partitions and the EOT position has been reset. In this particular case, because of the layout of data across partitions on the MVC, the %Used, %Avail and %Frag calculated values have changed significantly.

  The partition size for a T10KB MVC is 4727MB. The following VTVs demonstrate the defrag THRESH of 90% in the command selecting appropriately sized VTVs to move.

  A THRESH of 90% for a 4727MB partition gives a VTV used space threshold size of 473MB, that is, VTVs < 473MB will be subject to defrag. Calculated VTV sizes are rounded up by 1MB.

  The VTVs in Figure 2-11 existed on DMV601 before the RECLAIM command was issued:

  Figure 2-11 VTVs Before Reclaim

  
  

  After the RECLAIM has completed, the same section of the detail report now appears as shown in Figure 2-12.

  Figure 2-12 VTVs After Reclaim

  
  

  VTV DX1014, on partition 0006, is not eligible for defrag because the previous VTV, DX1012, also spans into partition 0006. The total used space of the two VTVs, which needs to be recalled to free the partition, is greater than the threshold size of 473MB for the partition.

  VTVs DX1016-DX1024 were all moved off by defrag because their size of 409.6MB, rounded up to 410MB, is less than the threshold used space of 473MB for the partition.

  VTV DX4000 was moved off by defrag because its size is 471.04MB, rounded up to 472MB, is less than the threshold size of 473MB for the partition.

  VTV DX4003 was not eligible for defrag because its size is 472.06MB, rounded up to 473MB, is not less than the threshold size of 473MB for the partition.

  VTV DX4006 was not eligible for defrag because its size is 473.08MB, rounded up to 474MB, is not less than the threshold size of 473MB for the partition.

  VTVs DX1028-DX1098 were all moved off by defrag because their size of 409.6MB, rounded up to 410MB, is less than the threshold used space of 473MB for the partition.

• To stop data movement occurring from VMVCs in a VLE, specify MOVEDATA(Minimum) or MOVEDATA(None) on dynamic reclaim commands targeting Storage Classes in their VLE(s).

  The following example shows an MVC Report with three VLE MVCs.

  Figure 2-13 Three VLE MVCs with MOVEDATA(Minimum)

  
  

  When MOVEDATA(Minimum) is specified:

  RECLAIM STORCLAS(S0) THRESHLD(15) MOVEDATA(MINIMUM)
  

  VMVC VMC000 contains VTVs with changed MGMTclas definitions specifying different STORclas(es). It is above the THRESHLD value. It has empty partitions.

  VMVC VMC001 is above the THRESHLD value. It has empty partitions. There are no VTVs with MGMTclas definitions requiring reconciliation, movement, or other actions.

  VMVC VMC002 is above the THRESHLD value.

  After specifying MOVEDATA(Minimum), the MVC report appears as shown in Figure 2-14.

  Figure 2-14 VLE MVC Report After MOVEDATA(Minimum) Specified

  
  

  Each VMVC has had all the space reclaimed and no data movement has occurred for any of them due to the MOVEDATA(Minimum) parameter.

  For VLE VMVCs the same result would have occurred if MOVEDATA(None) had been specified.

VLE Reclaim Threshold - Determines VMVC Eligibility for Reclamation

Table 2-29 VLE Reclaim Threshold

Policy:	Values:	Default:	Command to Set Policy:
Specifies the reclaim threshold (as a percentage) that determines when an VMVC is eligible for demand or automatic reclamation.	4 - 98	30	CONFIG RECLAIM VLTHRES

Usage Notes

• CONFIG RECLAIM VLTHRES applies only to VMVCs.

• VLE MVC media (VMVCs) is subject to fragmentation and must be reclaimed just like real MVCs. The VMVC reclaim process, however, uses far fewer resources than a standard reclaim. The reclaim threshold for a VMVC is specified through the CONFIG RECLAIM VLTHRES parameter. The lower that you set VLTHRES, the more frequent VTCS will run reclaim on the VMVCs and the greater the effective capacity of the VMVCs (less fragmentation).

Free MVCs Threshold - Starts Automatic Space Reclamation

Table 2-30 Free MVCs Threshold

Policy:	Values:	Default:	Command to Set Policy:
Specifies the minimum number of free MVCs. If the actual number drops below this value, automatic reclamation starts.	0 - 255	40	CONFIG GLOBAL MVCFREE

Usage Notes

• A free MVC has 100% usable space and does not contain any migrated VTVs.

• VTCS checks the MVCFREE value for each ACS. VTCS issues message SLS6616I and starts an automatic space reclamation if both of the following occurs:

  • Free MVCs is equal to or less than the value specified on CONFIG MVCFREE.

  • There is at least one eligible MVC as defined by the CONFIG RECLAIM THRESHLD parameter; for more information, see "Eligible/Total MVCs Threshold - Starts Automatic Space Reclamation."

• If you set MVCFREE=0, VTCS actually uses the default value (40).

• Oracle strongly recommends that you ensure that your MVC pool always has at least one eligible MVC for each MVC media type.

  Otherwise, you may need to change the CONFIG GLOBAL MVCFREE value, add more MVCs to the pool, or both. You can use Display to display the number of free MVCs in your MVC pool.

Eligible/Total MVCs Threshold - Starts Automatic Space Reclamation

Table 2-31 Eligible/Total MVCs Threshold

Policy:	Values:	Default:	Command to Set Policy:
Specifies a percentage value that represents the ratio of reclaim candidates to total MVCs, which triggers automatic space reclamation as described in "Usage Notes."	1 - 98	35	CONFIG RECLAIM START

Usage Notes

• CONFIG RECLAIM START specifies a percentage value, which is equal to:

  (Reclaim Candidates/Reclaim Candidates + Free MVCs) * 100
  

  Where:

  Reclaim Candidates

  The number of Reclaim Candidates determined by the CONFIG RECLAIM THRESHLD parameter. For more information, see "Eligible/Total MVCs Threshold - Starts Automatic Space Reclamation."

  Reclaim Candidates + Free MVCs

  Equals the number of Reclaim Candidates plus the number of free MVCs. A free MVC:

  • has 100% usable space and does not contain any migrated VTVs.

  • is defined as described in "Defining MVCs."

  • is writeable.

  • is resident in the ACS.

• For each ACS (not globally for all ACSs), VTCS issues message SLS6616I and starts an automatic space reclamation if both of the following occurs:

  • The actual value of (Reclaim Candidates/Reclaim Candidates + Free MVCs) * 100 exceeds the value specified on CONFIG RECLAIM START parameter.

  • The number of eligible MVCs exceeds the value specified on the MAXMVC parameter; for more information, see "Maximum MVCs Processed Per Reclaim."

    Note:

    The only exception to the above two conditions occurs if an SLS6699 message indicates a critical shortage of free MVCs, in which case automatic reclamation will start anyway.

• The following are general guidelines for specifying values for the START parameter:

  • A low value (for example, 5%), starts automatic space reclamation when there are few eligible MVCs compared to free MVCs unless you set the MAXMVC value high compared to the number of eligible MVCs.

  • A high value (for example, 95%), starts automatic space reclamation when there are many eligible MVCs compared to free MVCs unless you set the MAXMVC value very high and your MVC pool is very small.

• You can use Display MVCPOOL to display eligible and free MVCs.

Maximum MVCs Processed Per Reclaim

Table 2-32 Maximum MVCs Processed Per Reclaim

Policy:	Values:	Default:	Command to Set Policy:
Specifies the maximum number of MVCs that will be processed in a single space reclamation run.	1 - 98	40	CONFIG RECLAIM MAXMVCRECLAIM MAXMVC

Usage Notes

• Automatic and demand space reclamation processes one MVC at a time. You can, however, use MAXMVC to control the maximum number of MVCs that will be processed in a single space reclamation run (automatic or demand).

• For automatic space reclamation to start using the CONFIG RECLAIM START parameter setting, the number of eligible MVCs (determined by the CONFIG RECLAIM THRESHLD parameter) must also exceed the MAXMVC value. For more information, see "Eligible/Total MVCs Threshold - Starts Automatic Space Reclamation."

• The following are general guidelines for specifying values for the MAXMVC parameter:

  • A low value reclaims fewer MVCs in a single run but may have negligible effect on migrations and recalls and may start automatic space reclamation more frequently; for more information, see "Eligible/Total MVCs Threshold - Starts Automatic Space Reclamation."

  • A high value reclaims more MVCs in a single run but may have considerable effect on migrations and recalls and may start automatic space reclamation less frequently; for more information, see "Eligible/Total MVCs Threshold - Starts Automatic Space Reclamation."

• You can use Display MVCpool to display eligible and free MVCs.

Maximum MVCs Concurrently Processed for Reclamation and Drain

Table 2-33 shows maximum MVCs concurrently processed for reclamation and drain.

Table 2-33 Maximum MVCs Concurrently Processed for Reclamation and Drain

Policy:	Values:	Default:	Command to Set Policy:
Specifies the maximum number of MVCs concurrently processed for reclamation and drain.	1 - 99	1	CONFIG RECLAIM CONMVC MVCDRAIN CONMVC RECLAIM CONMVC

Hosts Disabled from Reclamation

Table 2-34 shows hosts disabled from reclamation.

Table 2-34 Hosts Disabled from Reclamation

Policy:	Values:	Default:	Command to Set Policy:
Specifies that a host cannot initiate automatic and demand reclamation.	NORECLAM, if not specified, reclamation is not disabled	Do not disable	CONFIG HOST NORECLAM

Usage Notes

• Specifying NOMIGRAT also causes NORECLAM to be set.

• Disabled hosts can still do demand MVC drains using MVCDRain.

MVC Retain Interval

Table 2-35 MVC Retain Interval

Policy:	Values:	Default:	Command to Set Policy:
Specifies how long VTCS will retain an MVC on an RTD in idle mode after a migration.	1 - 60 minutes	10	CONFIG VTSS RETAIN parameter

Usage Notes

• Retaining the MVC can reduce MVC mounts.

• When VTCS shuts down, VTCS dismounts all MVCs regardless of the MVC retain interval.

MVC Mount Timeout Interval

Table 2-36 MVC Mount Timeout Interval

Policy:	Values:	Default:	Command to Set Policy:
Specifies the interval before MVC mount timeout.	5 - 30 minutes	15	CONFIG GLOBAL MVCMNTTO=nn parameter

Non-Library Resident MVC Policies

The non-library resident MVC policies specify how VTCS processes MVCs that are not in the ACS.

Table 2-37 Non-Library Resident MVC Policies

Policy:	Values:	Default:	Command to Set Policy:
Specifies how VTCS handles the mount of non-library resident MVCs during drain/reclaim processing.	YES (VTCS requests the mount of the non-library MVC), NO (VTCS suppresses the mount and purges the request). Note: For reclaim, only library resident MVCs can be selected for processing, never non-library ones. However, between the time a library resident MVC is selected and the time it is actually processed, it may have become non-resident by being ejected. For drain, non-library resident MVCs can be selected.	YES	CONFIG GLOBAL NLIBDRNR
Specifies whether non-library resident MVCs are selected for migration processing.	YES, NO	YES (select non-library resident MVCs for migration)	CONFIG GLOBAL NLIBMIGR
Specifies whether non-library resident MVCs are selected for reclamation processing.	YES, NO	YES (select non-library resident MVCs for reclamation)	CONFIG GLOBAL NLIBRECL

MVC Initialization on First Mount

Table 2-38 MVC Initialization on First Mount

Policy:	Values:	Default:	Command to Set Policy:
Specifies whether uninitialized MVCs are initialized when first mounted.	NO, YES	NO for CONFIG GLOBAL, none for MVCPOOL	CONFIG GLOBAL INITMVC parameter,MVCPOOL NAME INITMVC parameter

Note:

• MVCPOOL INITMVC overrides GLOBAL INITMVC. There is no default for MVCPOOL INITMVC; if not specified for a named MVC Pool the CONFIG GLOBAL value (or default) is used.

• Initialization of MVCs in the DEFAULTPOOL is controlled by the GLOBAL INITMVC specification (or default).

• MVC Initialization applies only to VSM4/5 and requires microcode level D02.05.00.00 or higher. If this level of microcode is not installed on all VTSSs in the configuration, MVC initialization will be limited to the VTSSs that have it installed.

---

Footnote Legend

Footnote 1: There is one exception, VTV size (MAXVtvsz on MGMTclas).