You can use this section to create VTCS Management and Storage Classes and perform common tasks associated with them.
VTCS Management and Storage Classes, which are the building blocks of a lot of leading edge implementations, do the following:
VTCS Management Classes specify how VTCS manages VTVs. The HSC MGMTclas control statement defines a Management Class and its attributes. For example, the DELSCR parameter of the MGMTclas statement specifies whether VTCS deletes scratched VTVs from the VTSS.
Management Classes can also point to VTCS Storage Classes. VTCS Storage Classes, which specify where migrated VTVs reside. The HSC STORclas control statement defines a Storage Class and its attributes. For example:
MGMT NAME(PAYROLL) MIGPOL(LOCAC,REMAC) STORCLAS NAME(LOCAC) ACS(00) MEDIA(STK1R) STORCLAS NAME(REMAC) ACS(01) MEDIA(STK2P,ZCART)
This combination of Management and Storage Classes says ”For Management Class PAYROLL, migrate duplexed to separate MVCs in the local and remote ACSs. In the local ACS, put it on 9840 media so you can get it back in a hurry if you need it. In the remote ACS, prefer 9940 over ZCART media, but definitely put it in Deep Storage there.”
Start with "Creating and Using VTCS Management and Storage Classes: The Basics," which is a basic procedure you can adjust for any of your business needs. Next, it is on to "Leading Edge Techniques You Can Do with Management and Storage Classes." Think of this section as a gallery where you get to see a variety of options, then pick out the one that works best for you.
You see this pattern a lot (TAPEREQ > POLICY > MGMTclas > STORclas), so get to know it, because it is the foundation for all the information in "Leading Edge Techniques You Can Do with Management and Storage Classes."
Determine the definition data set that contains the STORclas and MGMTclas statements.
MGMTclas and STORclas statements must reside in the same data set for cross-validation.
Define Storage Classes through the STORclas control statement.
As desired, adjust the migration policies with MIGRSEL and MIGRVTV statements.
Define Management Classes with the MGMTclas control statement.
Note that the MGMTclas control statement specifies Storage Classes on various parameters.
Load the control statements with the HSC MGMTDEF command.
Specify a tape policy on the SMC POLICY command.
Specify the Policy name to VTCS on either of the following:
The SMC TAPEREQ statement.
SMS routines that you write to the StorageTek DFSMS interface.
Note the following:
Always use an SMC POLICY command to assign the Management Class to mounts.
You can specify a policy with either the TAPEREQ statement or SMS routines.
Use POLICY VALIDATE to ensure that your SMC POLICY statements all reference VALID MGMTCLAS names.
You can use the VTVMAINT utility to change a VTV's Management Class. Also note that while you cannot use VTVMAINT to directly change a VTV's Storage Class, you can use VTVMAINT to change a VTV's Management Class, which can reference a different Storage Class.
Use only the minimum Storage Classes required to define the policies you want to implement. Excessive Storage Classes can impact VSM performance due to the MVC mount/dismount overhead incurred. In addition, an MVC can only contain VTVs in a single Storage Class, so excessive Storage Classes can underuse MVC space.
If you decide to delete a Management Class definition, run a VTV Report to make sure that the Management Class is no longer assigned to any VTVs, otherwise unpredictable results occur!
The following is not an exhaustive list, just the most common tasks you can do with Management and Storage Classes:
Using the STORclas MEDIA Parameter for MVC Media Preferencing. There are defaults for MVC media preferencing, but you can adjust them any way you want. For more information, see Managing HSC and VTCS.
"Grouping Multiple Workloads on Shared MVCs." This was our introductory example, and is a good one if your company owns the data center, and you want to optimize use of your available resources by:
Duplexing critical data to separate MVCs in the local and remote ACSs. In the local ACS, put it on 9840 media so you can get it back in a hurry if you need it. In the remote ACS, prefer 9940 over ZCART media for deep storage on high-capacity media.
Giving two critical jobstreams (payroll and accounting) access to these Management/Storage Classes. Result: all your payroll and accounting data is duplexed local and remote, grouped on the same set of MVCs of the appropriate media discussed in the Storage Class specifications.
Production data is also critical, but you want it on a separate set of MVCs from the ones used for payroll and accounting data. No problem, just create another Management Class/Storage Class combination for production data, and you are done.
"Segregating Individual Workloads on Separate Sets of MVCs." All you service groups, study this one carefully, because you will probably use it a lot. Ever want to give each of your clients his/her own set of resources for billing/security purposes? Segregating workloads is the key.
"Archiving Data." In this scenario, you can use VTCS to mimic HSM in the StorageTek automated tape/virtual tape environment only. That is, you can use the ARCHAge and ARCHPol parameters of the MGMTclas statement to set an Archive Policy for VTVs in a Management Class.
Information Lifecycle Management (ILM), a StorageTek storage management strategy, has as its central concept the idea that data should be stored on media that matches its importance to the business enterprise and its pattern of reuse. Active, important data goes on fast-access media, and has multiple copies, while inactive, less important data is archived to high-capacity, cheaper media. Automating this process is the most cost-effective way to manage data storage. Archiving implements ILM by letting you archive inactive data. Using VTCS archiving, you can move VTVs to different media (for example, from fast-access 9840 media to high-capacity 9940 media) and a different location (for example, from a local ACS to a remote ACS for ejection/vaulting). For the details, see "Archiving Data."
"Reconciling VTV Media and Location." Think of archiving as a proactive move. You put the data on the right media at the beginning of the ILM cycle, then move it to other media as the data ages. What happens if the data ends up on the wrong media? Answer: use the RECONcil utility to move it from one Storage Class to another.
Controlling VTV Migration. ELS allows very fine control over VTV migration, including deleting scratch VTVs from the VTSS buffer, specifying the immediate migrate delay interval, and specifying the maximum VTV residency interval. For more information, see Configuring HSC and VTCS and ELS Disaster Recovery and Offsite Data Management Guide.
You can use Storage and Management Classes to group multiple workloads on a shared set of MVCs. For example, the STORclas statements below define Storage Classes LOC1, LOC2, REM1, and REM2.
STORCLAS NAME(LOC1) ACS(00) MEDIA(STK1R) STORCLAS NAME(LOC2) ACS(00) MEDIA(STK1R) STORCLAS NAME(REM1) ACS(01) MEDIA(STK2P,ZCART) STORCLAS NAME(REM2) ACS(01) MEDIA(STK2P,ZCART)
Management Classes PAY and ACCOUNT both specify the LOC1 and REM1 Storage Classes on the MIGPOL parameter. The VTVs in PAY and ACCOUNT, therefore, are duplexed and grouped on the MVCs defined by Storage Classes LOC1 and REM1.
Management Class PROD specifies the LOC2 and REM2 Storage Classes on the MIGPOL parameter. The VTVs in PROD, therefore, are duplexed and grouped on the MVCs defined by Storage Classes LOC2 and REM2, which are separate from those for PAY and ACCOUNT.
MGMT NAME(PAY) MIGPOL(LOC1,REM1) MGMT NAME(ACCOUNT) MIGPOL(LOC1,REM1) MGMT NAME(PROD) MIGPOL(LOC2,REM2)
The following defines tape policies that specify virtual media and respectively assign Management Classes PAY, ACCOUNT, and PROD.
POLICY NAME (PPAY) MEDIA(VIRTUAL) MGMT(PAY) POLICY NAME (PACCOUNT) MEDIA(VIRTUAL) MGMT(ACCOUNT) POLICY NAME (PPROD) MEDIA(VIRTUAL) MGMT(PROD)
Finally, this example consists of TAPEREQ statements that assign policies as follows:
Data sets with qualifiers of PAYROLL.** are assigned policy PPAY.
Data sets with qualifiers of ACCOUNTS.** are assigned policy PACCOUNT.
All other data sets are assigned policy PPROD.
TAPEREQ DSN(PAYROLL.**) POLICY(PPAY) TAPEREQ DSN(ACCOUNTS.**) POLICY(PACCOUNT) TAPEREQ DSN(**) MEDIA(VIRTUAL) POLICY(PPROD)
Once an MVC is used for a Storage Class it remains exclusively assigned to that Storage Class while it contains current VTV copies. This grouping of VTVs on MVCs are retained even after the MVCs undergo reclamation processing.
Caution:
You cannot use the default Storage Class (the name of the last VTSS that wrote to the MVC for reclamation or migration) to group workloads.You can use Storage and Management Classes to segregate individual workloads on separate sets of MVCs. For example, the STORclas statements below define Storage Classes LOC, CUSTA, and CUSTB1, and CUSTB2.
STORCLAS NAME(LOC) ACS(00) MEDIA(STK1R) STORCLAS NAME(CUSTA) ACS(00) MEDIA(STK1R) STORCLAS NAME(CUSTB1) ACS(00) MEDIA(STK1R) STORCLAS NAME(CUSTB2) ACS(01) MEDIA(STK2P)
The example below defines the following Management Classes:
Management Class CUSTA specifies the CUSTA Storage Class on the MIGPOL parameter. VTCS simplexes VTVs in this Management Classes to only the CUSTA Storage Class (9840 media in the local ACS), because that is what this customer wants.
Customer B wants more protection, namely duplexing to the local and remote ACSs, so Management Class CUSTB points to both the CUSTB1 and CUSTB2 Storage Classes.
Finally, local ACS/9840 media is just fine for your own production data, so that is what Management Class PROD does. What you probably also do is set up an Archive Policy for this Management Class (see "Archiving Data") so you can move it to Deep Storage eventually.
MGMT NAME(CUSTA) MIGPOL(CUSTA) MGMT NAME(CUSTB) MIGPOL(CUSTB1,CUSTB2) MGMT NAME(PROD) MIGPOL(LOC)
This example defines tape policies that specify virtual media and respectively assign Management Classes PAY, ACCOUNT, and PROD.
POLICY NAME (PCUSTA) MEDIA(VIRTUAL) MGMT(CUSTA) POLICY NAME (PCUSTB) MEDIA(VIRTUAL) MGMT(CUSTB) POLICY NAME (PPROD) MEDIA(VIRTUAL) MGMT(PROD)
Finally, the example below shows the corresponding TAPEREQ statements and policy assignments:
Data sets with HLQ CUSTA are assigned policy PCUSTA.
Data sets with HLQ CUSTB are assigned policy PCUSTB.
All other data sets are assigned policy PPROD.
TAPEREQ DSN(CUSTA.**) POLICY(PCUSTA) TAPEREQ DSN(CUSTB.**) POLICY(PCUSTB) TAPEREQ DSN(**) POLICY(PPROD)
Caution:
You cannot use the default Storage Class (the name of the last VTSS that wrote to the MVC for reclamation or migration) to segregate workloads.You can use the ARCHAge and ARCHPol parameters of the MGMTclas statement to set an Archive Policy for VTVs in a Management Class. When the VTV's age exceeds the ARCHAge value, the VTV is eligible for archive for the Storage Class(es) specified on the ARCHPol parameter. The actual archive occurs in one of two ways:
Automatically the next time the VTV is recalled and remigrated.
On demand using the ARCHIve utility.
A ”what if” for this might be to ensure compliance. It turns out that you have data that you have to retain for 7 years for external auditors, but your internal auditors might like to look at it once a year as well. Here is what that solution looks like:
TAPEREQ DSN(COMPLY.**) POLICY(PCOMPLY) POLICY NAME(PCOMPLY) MEDIA(VIRTUAL) MGMT(COMPLY) MGMT NAME(COMPLY) IMMMED(DELETE) MIGPOL(LOC1) - ARCHAGE(365) ARCHPOL(REMDEEP) STOR NAME(LOC1) ACS(00) MEDIA(STK1R) STOR NAME(REMDEEP) ACS(01) MEDIA(STK2P)
For this scenario, the following occurs:
All compliance data is immediately migrated to the local ACS and grouped on 9840 media. After the migration succeeds, the VTVs are deleted from the VTSS. The ”archive age” for this data is 365 days, in case the internal auditors want to see it in the next year.
After that, the data is eligible to be archived (moved to) 9940 media in the remote ACS.
Result: Compliance, at the best possible cost, while optimizing virtual resources.
As noted above, you have two methods to use for the actual archive: wait until the VTV is recalled and migrated, or do it on demand using the ARCHIve utility. The problem with waiting for remigration is that this is data that is not likely to be accessed. The chances are, the best way to archive VTVs is to run the ARCHIve utility periodically or as-needed.
Here are some tips for using the ARCHive utility:
To select the VTVs to archive, you can specify one of the following parameters:
MGMTclas to archive the VTVs in Storage Class(es) specified by the ARCHAge/ARCHPol parameter of the specified Management Class(es).
VTV to archive a list or range of VTVs for the Management Class(es) for those VTVs.
Note:
If you do not specify a value for MGMTclas or VTV, VTCS scans all VTVs. You should probably do business through Management Class, but you can see situations where you want to do it by VTV volser or all VTVs.By not specifying the MOVEVTV parameter, you can get a report (only) that is a valuable "what if" picture of how many VTVs, MVCs, and total MBs you process with an archive request. Oracle strongly recommends, therefore, that you first run ARCHIve without MOVEVTV, then adjust the job as needed before specifying MOVEVTV. For more information, see ELS Command, Control Statement, and Utility Reference.
Because demand archive can be resource intensive, you typically run ARCHIve during non-peak processing periods. You can also use the ARCHIve utility to override the CONFIG RECLAIM THRESHLD, MAXMVC, and CONMVC settings to optimize archive performance. You can also specify the maximum time for the archive in minutes on the ELAPSE parameter. Note that there are several limiting factors that influence archives (for example, MAXMVC and ELAPSE). VTCS enforces the strictest limiting factor. For example, if you run ARCHIve and specify ELAPSE equal to 5 hours and MAXMVC equal to 10 and VTCS archives 10 MVCs in one hour, then VTCS terminates the archive before the ELAPSE value expires.
VTCS and HSC must be active to process a ARCHIve request except when you specify the POLICYdd parameter. POLICYdd (which forces ”report only” mode) also provides an enhanced ”what if” capability. You can create one or more alternate MGMTclas statements with different Archive Policies (different ARCHAge and ARCHPol values), and use POLICYdd to view the Archive Policy and resource use for each scenario.
The RECONcil utility looks like ARCHive because RECONcil also moves VTVs from one Storage Class to another (that is, moves them from one MVC media to another and/or moves them from one ACS to another). Think of ARCHive as proactive and RECONcil as reactive, and you see the difference, as described in "Reconciling VTV Media and Location."
If the 365 days is up, and the internal auditors have not shown up, time to go to archive. The example below shows JCL to run ARCHive as follows:
Archive VTVs in Management Classes COMPLY to 9940 media in the remote ACS.
Set MAXMVC to 60, CONMVC to 8, and ELAPSE to 60 for the ARCHive job.
//ARCHIVE EXEC PGM=SLUADMIN //STEPLIBDD DSN=hlq.SEALINK,DISP=SHR //SLSPRINTDD SYSOUT=* //SLSINDD * ARCH MGMT(COMPLY) MAXMVC(60) CONMVC(8) ELAPSE(360) MOVEVTV
Tip:
The MOVEVTV parameter also gives you a report, so you can see how well (or not) you did. If your tuning parameters did not archive everything you wanted to archive, then adjust your job and rerun.Using RECONcil to reconcile VTV media and location basically means moving VTVs from one Storage Class to another. Is this at all like archiving data with ARCHive? In terms of data movement, yes. In terms of the reasons why you are doing it, it is a reactive rather than proactive move. You typically reconcile VTVs when:
The VTVs are on the wrong media, in the wrong ACS, or both.
An ACS is unavailable for a considerable period of time, then is brought back online. In this case, you first change the MIGpol parameter on the MGMTclas statement for the affected VTVs to point to a different ACS (and media, if desired). When the original ACS comes back online, you then change the MIGpol parameter on the MGMTclas statement to point to the original ACS, and run RECONcil specifying the updated MGMTclas (or STORclas) statement(s) to move the VTVs to the original ACS.
For details of the reconciling process, see "RECONcil Example."
If you want to reconcile VTVs that are on the wrong media and in the wrong ACS, how would you know this? Peruse your VTV reports on a weekly basis as described in Managing HSC and VTCS. This week, you notice that all the VTVs in your production (PROD) Management Class are on the wrong media and in the wrong ACS! And the Storage Class does not look like the correct one, either.
How could this have happened? You thought you did the following:
STORCLAS NAME(LOC) ACS(00) MEDIA(STK1R) STORCLAS NAME(CUSTA) ACS(00) MEDIA(STK1R) STORCLAS NAME(CUSTB1) ACS(00) MEDIA(STK1R) STORCLAS NAME(CUSTB2) ACS(01) MEDIA(STK2P MGMT NAME(CUSTA) MIGPOL(CUSTA) MGMT NAME(CUSTB) MIGPOL(CUSTB1,CUSTB2) MGMT NAME(PROD) MIGPOL(LOC)
According to this example, everything in Management Class PROD should have ended up on 9840 media in the local ACS, but in fact, they are all on 9940 media in the remote ACS, almost as if they were in the wrong Storage Class.
On closer examination, the production Management Class actually looks like this:
MGMT NAME(PROD) MIGPOL(CUSTA)
This is not good for another reason, because it means the production data is co-resident on the same MVCs that are supposed to be dedicated to one of your customers. Time to run RECONcil, right? Perhaps not. RECONcil only moves VTVs out of the wrong Storage Class, and right now, according to the way you wrote your Management Class statement, CUSTA is the right Storage Class! Before you run RECONcil, you have to go back and fix the Management Class as follows:
MGMT NAME(PROD) MIGPOL(LOC)
Now you can run RECONcil as shown below:
Move VTVs in Management Class PROD to their (updated) correct location in Storage Class LOC.
Set MAXMVC to 60, CONMVC to 8, and ELAPSE to 60 for the RECONcil job.
//RECONCIL EXEC PGM=SLUADMIN //STEPLIBDD DSN=hlq.SEALINK,DISP=SHR //SLSPRINTDD SYSOUT=* //SLSINDD * RECON MGMT(PROD) MAXMVC(60) CONMVC(8) ELAPSE(360) MOVEVTV
To select the VTVs to reconcile, you can specify one of the following parameters:
MGMTclas to move the VTVs to the Storage Class(es) specified by the MIGpol parameter. This is what was done in "RECONcil Example." Management Class points to the wrong Storage Class, get it pointed toward the right Storage Class, run RECONcil against the updated Management Class.
STORclas to move the VTVs to the specified Storage Class(es). You probably use this when an ACS is unavailable for a considerable period of time.
MVC to reconcile the VTVs on a list or range of MVCs. The VTVs are moved to the Storage Class(es) specified by the MIGpol parameter of the MGMTclas statement(s) for the VTVs. You can use this first followed by the VTV option.
VTV to reconcile a list or range of VTVs. The VTVs are moved to the Storage Class(es) specified by the MIGpol parameter of the Management Class(es) for the VTVs.
Note:
If you do not specify a value for MGMTclas or VTV, VTCS scans all VTVs.
Because reconciling VTVs can be resource intensive, you typically run RECONcil during non-peak processing periods. You can also use the RECONcil utility to override the CONFIG RECLAIM THRESHLD, MAXMVC, and CONMVC settings to optimize reconcile performance. You can also specify the maximum time for the reconcile in minutes on the ELAPSE parameter.
Note that there are several limiting factors that influence reconciliations (for example, MAXMVC and ELAPSE). VTCS enforces the strictest limiting factor. For example, if you run RECONcil and specify ELAPSE equal to 5 hours and MAXMVC equal to 10 and VTCS reconciles 10 MVCs in one hour, then VTCS terminates the reconciliations before the ELAPSE value expires.
By not specifying the MOVEVTV parameter, you can get a report (only) that is a valuable "what if" picture of how many VTVs, MVCs, and total MBs you process with a reconcile request. Oracle strongly recommends, therefore, that you first run RECONcil without MOVEVTV, then adjust the job as needed before specifying MOVEVTV.
For more information, see ELS Command, Control Statement, and Utility Reference.
VTCS and HSC must be active to process a RECONcil request except when you specify the POLICYdd parameter. POLICYdd (which forces "report only" mode) also provides an enhanced "what if" capability. You can create one or more alternate MGMTclas statements with different reconciliation scenarios (different MIGpol values), and use POLICYdd to view the VTVs reconciled and resource use for each scenario.
VTCS and HSC must be active to process a RECONcil request.
Named MVC Pools are the right tool for the job for all of your service groups: You can use Named MVC Pools to give an application ownership of the MVCs in the named pool. For example, a service group might elect to use Named MVC Pools where its customers have legal requirements to buy and own a group of MVCs.
However, if you do not have a specific requirement for Named MVC Pools but you do want to group or segregate client data on MVCs, Oracle strongly advises that you do not use Named MVC Pools. Instead, use the methods described in the following sections:
The above sections tell how to use Storage Classes to group or segregate data on MVCs that are selected from the system-wide MVC pool. In this case, you need to manage a only a single MVC pool.
If you create Named MVC Pools, you must explicitly manage each pool, which includes ensuring that each pool has sufficient free MVCs and available MVC space, and potentially includes setting different policies for each pool using the MVCPool MVCFREE, MAXMVC, THRESH, and START parameters.
If you elect to use Named MVC Pools, go to "Creating and Using Named MVC Pools."
To create and use Named MVC Pools, do the following:
Modify existing POOLPARM statements and/or add additional statements to define the Named MVC Pools.
If you do not specify the POOLPARM NAME parameter, VTCS does not create a Named MVC Subpool and assigns the specified volumes to the default pool (DEFAULTPOOL). You cannot create Named MVC Pools with the reserved names DEFAULTPOOL and ALL.
You can use the optional MVCFREE, MAXMVC, THRESH, and START parameters to specify values for the Named MVC Pool that override the global values specified on CONFIG.
For example, the following VOLPARM and POOLPARM statements defines a range of T10000 Full volumes to be encrypted for Named Pool SYS1MVCT1 with reclamation parameter values that override the CONFIG global values:
VOLPARM VOLSER(T10K2000-T10K2999)MEDIA(T10000T1)RECTECH(T1AE) POOLPARM NAME(SYS1MVCT1)TYPE(MVC)MVCFREE(40) MAXMVC(4) THRESH(60) START(70)
Run the SET VOLPARM to apply the volume and pool definitions:
SET VOLPARM APPLY(YES)
Define Storage Classes and associate them with Named MVC Pools.
For example, the following STORclas statement defines STORCL1 and associates this Storage Class with Named MVC Pool CUST1POOL. Requests to use MVCs for storage class STORC1 result in MVCs being selected only from the named pool SYS1MVCT1.
STOR NAME(STORCL1) MEDIA(T!AE) MVCPOOL(SYS1MVCT1)
Create Management Classes that specify the Storage Classes you defined in step 3 and specify these Management Classes when you route data to the Named MVC Pool.
For more information, see "Creating and Using VTCS Management and Storage Classes: The Basics."
Specify the Management Class name to VTCS on any of the following:
The SMC TAPEREQ statement.
SMS routines that you write to the StorageTek DFSMS interface. For more information, see SMC Configuration and Administration.