Welcome to the ”VTCS Must Do (Sometimes) Chores List,” also known as the ”As-Needed Tasks List.” For example, if this is the week you decide to run DELETSCR to zero out a list of scratched VTVs that are tying up major amounts of your valuable VTSS and MVC space. Great, job well done. How long do you think it is going to be before you have to run the same operation? Especially if you do not change your delete on scratch policies? Answer: It might be a day, a month, or a year, but you will get to do it again.
No worries, however. Useful procedures are discussed here to help you pare down the Must Do (Sometime) List, and, as you have already seen from reading "Using the VTCS Dashboard," if you keep a close eye on your MVC and VTV reports, you may not even need a list, because they tell you when it is time to do the Must Do/As Needed chores.
There is also another class of ”Must Do (Sometime)” chores that are almost policy decisions, but included here because (a) they are proactive in nature, which makes them doubly valuable as Best Practices ”As Needed” chores, and (b) they are operating techniques you can use, back out, and reintroduce as they benefit (or not) your shop at any point in time. Having said that, lead off with three of our favorites in this category as described in "Doing Demand Space Reclamations, Migrations, and Recalls."
These tasks are optional, but, especially in the case of Demand Space Reclamations, highly recommended Best Practices for reasons that soon become obvious.
As you already know, VSM automatically reclaims MVC space on each host running reclamations, the key word being automatically. That means that space reclamation is always out there looking for work, and although it is a background task, if you have got a lot of fragmented MVCs, the space reclamation work can seriously interfere with migration/recall, especially during peak processing periods.
If your MVC summary report or Display MVCPool shows a high level of fragmentation on your system's MVCs (and this level is below the value specified on the CONFIG RECLAIM THRESHLD parameter or the MVCPool THRESH parameter), you may want to schedule demand MVC space reclamation as an off-hours batch job.
You do demand MVC space reclamation with RECLaim. Open up your ELS Command, Control Statement, and Utility Reference and you see some useful tools you can use to optimize demand reclamation and run it most efficiently:
You can use one only of the MVCPOOL, STORCLAS, ACSid, or MVC parameters to filter the list of MVCs to process. Your MVC and VTV reports, as described in "Using the VTCS Dashboard," help you narrow the list of likely candidates to an MVC Pool, Storage Class, specific ACS, or range or list of MVCs. Input this list into RECLaim, and you are using the right tool for the job.
Note that if you do not specify one of these parameters, space reclamation selects MVCs from the Named MVC Pool (if implemented) or media type (for multiple MVC media environments) most in need of free space.
The parameters MAXMVC (max MVCs processed by a single space reclamation task), THRESH (MVC's fragmented percentage that make it a reclaim candidate), and CONMVC (the maximum number of MVCs that VTCS concurrently processes for both drain and reclaim) let you override the corresponding CONFIG RECLAIM global parameters for the demand reclamation. This gives you the ability to tune your demand migrations to be more or less aggressive than your automatic migrations.
NOWAIT is a way of speeding up the process and CONMVC is another tuning method for influencing the number of MVCs processed at a time (see ELS Command, Control Statement, and Utility Reference for details).
ELAPSE is a way to detect if no demand reclaims have happened within an interval you specify. If there are no reclaims in this period, the job stops.
Also note that VTCS enforces the strictest limiting factor. For example, if you run RECLAIM and specify ELAPSE equal to 5 hours and MAXMVC equal to 10 and VTCS reclaims 10 MVCs in one hour, then VTCS terminates the reclaim before the ELAPSE value expires.
VTCS and HSC must be active to process a RECLAIM request.
As already noted, VTCS/ELS is basically a server. For example, VSM automatically manages VTSS space and migrates VTVs to ensure a balance of optimum data availability, resource use, and data protection.
That is great for a stable environment, but what if you find out your VSM system is about to receive a whole lot of application data? Answer: It might be time to run a demand migration batch job to free VTSS space before the aforementioned peak tape processing event occurs.
You do demand migrates with, of course, MIGRATE, which provides the following options:
You can migrate VTVs:
by volser (repeats allowed)
the Management Class
the data set name associated with the VTV (most effective).
There is also a DELETE(YES) option that you may want to employ that deletes the VTV from VTSS space after a successful migration. You typically use DELete (YES) (the default) for VTVs not likely to be reaccessed. As an alternative, you can specify DELete (NO) to ensure that critical data is available and quickly migrated for VTVs likely to be reaccessed.
The NOWAIT option helps you speed up the process. That is all using MIGRATE Format 1; see ELS Command, Control Statement, and Utility Reference for details.
As an alternative, you can use MIGRATE Format 2 to do a demand migrate-to-threshold for all or specific VTSSs. That is a nice tool for getting your DBU where you want it, and VTCS deals with the details.
Also note that, with SET MIGopt, you can lower the high AMT to effectively force a demand migration.
VTCS provides an automatic recall process which starts when a job requests a data set on a VTV that is migrated to tape, but not VTSS-resident. What if, however, you have the reverse of the above situation? For example, you are doing end-of-year processing, and know there is a bunch of jobs that want to read data from VTVs that are on tape only. Demand recall is the solution.
RECALL provides you with all the flexibility of control you need:
As with MIGRATE, you can recall VTVs by volser, Management Class, or associated data set name.
You can specify the VTSS where you want to recall the VTVs. Otherwise, the default is the VTSS of creation, and there are some considerations associated with the VTSS recall policy. See ELS Command, Control Statement, and Utility Reference for details.
RECALWER lets you specify whether you want to recall VTVs with read data checks.
There is a NOWAIT option to speed things up.
There is a lot of RTD management that you confine to ”Finding and Fixing VTCS Problems,” because they are almost exclusively error recovery scenarios. Best Practices for RTDs would be to have enough of them and keep all of the above up and running. Remember, RTDs get used for migrates, recalls, and reclaims, so keeping the right mix of RTDs for all of these jobs is a critical balancing act. To adjust this mix through operating parameters, see "Checking Virtual Tape Status (Daily)."
In addition to adjusting the RTD operating parameters, the other main tool you have with RTDs is the VTCS Vary RTD command, which you use to change RTD states. You can vary RTDs online, offline, or into maintenance mode if you need to do maintenance on the RTD.
The major as-needed tasks you are likely to encounter are related, and the first two use Vary RTD:
"Changing RTD Device Types," which is basically how to do a technology upgrade of some or all of your system's RTDs.
You need to consider the way you specify MVC media. Even though these are really MVC considerations, they occur because of a change of RTD device types. For more information, see Configuring HSC and VTCS.
Use the following procedure to change RTD device types. Note that changing RTD device types requires you to stop VTCS on all hosts.
To change RTD device types, do the following:
Review your VSM policies.
For example, you may want to review your Management Class and Storage Class definitions if this RTD device type is used for migrations.
Vary the old RTDs offline to VTCS.
If the new RTD devices use new MVS device addresses, do the following:
Define the new addresses to MVS.
Run DECOM to output your CONFIG statements.
Edit the CONFIG statements to change the RTD addresses to the new values.
Run CONFIG RESET.
Caution:
Do not vary the new transports online to MVS! Otherwise, they can be allocated as Nearline transports.Install the new RTDs.
Vary the LSM(s) where transports were replaced to offline status.
Vary the LSM(s) where transports were replaced to online status.
Vary the new RTDs online to VTCS.
If necessary, add MVCs.
For more information, see "Adding MVCs."
As you already know, it is somewhat difficult to limit a discussion to any one of your virtual entities. MVCs contain VTVs, so it is hard to talk about either in isolation, because you inevitably end up talking about the other. And if you are discussing VTVs, you are also talking about VTSSs and VTDs.
Having said that, the following sections are some basic procedures for doing fairly typical ”as-needed” tasks with MVCs that are done for a number of reasons. For example, you might add MVCs because you are running out of space as described in the previous scenario or because you are being proactive and do not want to get into trouble.
Note:
If you delete MVCs from the configuration as a result of either SET VOLPARM or CONFIG MVCVOL processing:You cannot re-enter the volsers into the configuration as VTVs.
Do not use the volsers for native HSC tapes.
Message SLS6944I indicates the number of MVCs that have been deleted.
If you have not heard, ELS 7.2 just made adding volumes a whole lot easier. You now use the HSC VOLPARM and POOLPARM statements to define all volumes and their pools: native Nearline volumes, cleaning cartridges, MVCs, and VTVs, and the HSC SET VOLPARM utility to load them. For more information, seem Configuring HSC and VTCS and ELS Command, Control Statement, and Utility Reference.
To add MVCS:
Create a VOLPARM statement to define the MVCs.
For example, to define a range of T10000 Full volumes to be encrypted:
VOLPARM VOLSER(T10K2000-T10K2999)MEDIA(T10000T1)RECTECH(T1AE)
Create a POOLPARM statement to define the MVC pool.
For example, to define the T10000 MVC Pool with reclaim parameters:
POOLPARM NAME(SYS1MVCT1)TYPE(MVC)MVCFREE(40) MAXMVC(4) THRESH(60) START(70)
Create or update your MGMTCLAS or STORCLAS statements as needed.
For example, if you added a new MVC media type, follow the recommendations in Configuring HSC and VTCS.
Update your POLICY or TAPEREQ output parameters as required.
For example, if you created a new Management Class in step 3, update or create your TAPEREQ or POLICY statements to point to the new Management Class.
Do you need to define VTVs?
If so, go to "Defining VTVs." Otherwise, go to "Validating and Applying the Volume Definitions."
To define VTVs:
Create POOLPARM or VOLPARM statements to define the VTVs.
For example, to define two ranges of VTVs for use by hosts MVS1 and MVS2:
POOLPARM NAME(SYS1VTV1)TYPE(SCRATCH) VOLPARM VOLSER(V5000-V5499)MEDIA(VIRTUAL) POOLPARM NAME(SYS1VTV2)TYPE(SCRATCH) VOLPARM VOLSER(V5500-V5999)MEDIA(VIRTUAL)
Run SET VOLPARM to validate the VOLPARM/POOLPARM statements.
SET VOLPARM APPLY(NO)
APPLY(NO) validates the statements without loading them. If you like the results, go to step 2. Otherwise, rework your volume definitions, then go to step 2.
Run SET VOLPARM to load the VOLPARM/POOLPARM statements.
SET VOLPARM APPLY(YES)
Physically enter any real cartridges into the ACS.
For more information, see "Entering Cartridges."
Why would you remove MVCs from the pool? A typical scenario might be that you are swapping out older drives for a technology refresh for your RTDs and you want to retire the old media, in which case, you get to add new MVCs to the pool as described in "Adding MVCs" and then remove the old media as described in "Permanently Removing MVCs."
Note that there are occasions where you might want to temporarily remove MVCs from the pool. For example, you have got some bad media or suspected bad media. You want to remove the bad media and put in replacements, basically under the same volsers as described in "Temporarily Removing MVCs."
To permanently remove MVCs from the pool, do the following:
Enter MVCDRain to drain the MVCs.
For example, to run the MVCDRain to drain the MVCs in Storage Class STORCL1, virtually eject the MVCs, and return after the request is submitted, enter the following:
MVCDRAIN STORCLAS(STORCL1) EJECT NOWAIT
If the MVCs are no longer required in an ACS, use an HSC Eject command to eject the MVCs from the ACS.
Remove the security restrictions, and tape management system restrictions you defined for the MVC.
If you use VOLPARM and POOLPARM definitions and the virtual CDS level is G or above, continue with step 4. Otherwise, go to step 5.
If you want to reuse the tape volser for Nearline (non-VTCS) usage and use VOLPARM/POOLPARM definitions:
Update the POOLPARM/VOLPARM statements for the MVCs you want to remove.
Run SET VOLPARM APPLY(YES) on all hosts to apply the changes.
Run the HSC SCRAtch command to scratch the volumes that are no longer MVCs.
If you want to reuse the tape volser for Nearline (non-VTCS) usage you do not use VOLPARM and POOLPARM, you need to do one of the following:
Issue an HSC EJECT command to remove the MVCs from the ACS.
Change the external bar code label on the cartridge.
You must change the external bar code label, because the original MVC volsers are retained in the CDS, and these volsers are only available for use as MVCs.
ENTER the cartridges back into the ACS.
OR
Create a new set of CDS data sets.
Run the HSC MERGECDS utility specifying DELVirt to remove unwanted MVC ranges.
Note:
All HSCs must be stopped when using this option since new CDS data sets are created.To temporarily remove MVCs from the pool:
Enter MVCDRain Eject for the MVC.
For example, to run the MVCDRain to drain the MVCs in Storage Class STORCL1, virtually eject the MVCs, and return after the request is submitted, enter the following:
MVCDRAIN STORCLAS(STORCL1) EJECT NOWAIT
This does the following:
Recalls all VTVs on the MVC and remigrates them to new MVCs.
Makes the MVC non-selectable for VTCS migrates.
To return the MVC to the MVC pool, enter an MVCDRain for the MVC.
Entering MVCDRain without the EJect parameter for the MVC makes it available again.
For example, to run the MVCDRain to drain the MVCs in Storage Class STORCL1 and return after the request is submitted, enter the following:
MVCDRAIN STORCLAS(STORCL1) NOWAIT
Note:
As an alternative, you can use MVCMAINT to mark an MVC as read-only. This prevents VTCS from selecting the MVC for migrates but does not remove the VTVs from the MVC. You can also use MVCMAINT to turn off read-only.If using VOLPARM/POOLPARM definitions, the NOMIGRAT option can be specified on the POOLPARM statement to prevent MVCs from being used for new migrations.
Use MVCDRain to ”drain” an MVC (recall all VTVs on the MVC). You typically drain an MVC for the following reasons:
An MVC report or Display shows data check errors for the MVC. VSM does not migrate to the MVC and you should remove it from the MVC pool.
An MVC report or Display shows errors other than data check errors for the MVC.
A Storage Class or Named MVC Pool is no longer in use and you want to remove or reuse the associated MVCs.
To select the MVCs to drain, you can specify one of the following parameters:
MVCid to drain one or more MVCs by volser.
MVCPOOL to drain the MVCs in a Named MVC Pool. See ELS Command, Control Statement, and Utility Reference for more information on Named MVC Pools.
STORCLAS to drain the MVCs in a Storage Class. See ELS Command, Control Statement, and Utility Reference for more information on Storage Classes.
You can use the MVCDRain to override the CONFIG RECLAIM CONMVC setting. You can run the MVCDRain from each host, which starts drain tasks on that host equal to the CONMVC value. These drain tasks can run concurrently with drain tasks initiated by other hosts.
Also note the following:
For VMVCs, MVCDRAIN with the EJECT parameter physically deletes the VTVs.
Caution:
If you use theDRCHKPT utility and/or the CONFIG GLOBAL PROTECT parameter to protect CDS backup content for VMVCs, specifying MVCDR EJECT invalidates the CDS backup's VMVC content.For both VMVCs and MVCs, MVCDRAIN without the EJECT parameter does not delete the VTVs, but updates the CDS record to show no VTVs on the VMVC/MVC.
For more information, see ELS Command, Control Statement, and Utility Reference.
MVCMAINT is a similarly handy tool in VSM Land, and its parameters describe its abilities:
First, MVC volser (range, list, individual volser) or MANIFEST are your two MVC selection criteria. MVC volser makes sense, but why MANIFEST? You create a manifest file (list of MVCs and the VTVs they contain) when you run EXPORT, which is something you might want to do when you are moving MVCs from one system to another. When you import the MVCs into the new system, it is probably a good idea if they started their new lives in read-only mode, so they do not get overwritten until you can define them properly.
READONLY (ON or OFF). See the previous bullet. Also, remember the discussion about adding MVCs to the pool? You might want to enter them into the ACS in scratch status, but some shops bring everything in as non-scratch and then sort things out. When you need to make writeable the new MVCs, MVCMAINT READONLY(OFF) is the tool.
LOST (ON or OFF). How does an MVC get lost? For example, can MVCs get lost? Believe it or not, they can. For example, if a VTCS-initiated mount of an MVC fails to complete (as opposed to completes with an error), VTCS marks the MVC as ”lost” in the CDS, and de-preferences it.
Multiplexed VTVs that reside on a ”lost” MVC are recalled from an alternate MVC. VTCS does not attempt to use ”lost” MVCs for migration unless there are no other valid MVCs. When an MVC in ”lost” status is successfully mounted, the ”lost” status is removed from the MVC record.
What if you know the MVC is not really lost? Answer: You can use MVCMAINT to turn off the LOST status.
There is an interesting use of MVCMAINT that deserves a mention. What if you have an LSM that is temporarily in manual mode? You might want to (temporarily) de-preference MVC selection in that LSM, which you can do with LOST(ON). Then, when the LSM is back in automatic mode, reverse the process with LOST(OFF).
ERROR (ON or OFF). An MVC can (erroneously) go into Error status for several reasons, for example:
VTCS does not recognize the volume mounted on the RTD as an MVC. This can be caused by some MVS job overwriting the MVC. Determine what happened to the MVC. If it no longer contains valid VTV data, reinitialize the volume and return it to the MVC pool.
The MVC is not writeable, which can be caused by the thumb wheel being set to read-only, or by the security package not allowing VTCS to write to the volume. Reset the thumb wheel, or change the rules in the security package to allow the MVC to be written to.
A bad block ID has been detected, and you have to (VTCS) audit the MVC to try to correct the condition.
After you correct the error condition as described, use MVCMAINT to reset the MVC status to ERROR(OFF).
EJECT (ON or OFF) specifies the ”logical eject” status of the MVC. How does this status get set, and why might you want to change it? If you explicitly drain an MVC using MVCDRAIN, it is probably because you think the media is bad, and so you de-preference it by setting on the ”logical eject” status. You then really eject the MVC, run some tests, find out it is just fine, and reenter it. At that point, use MVCMAINT) to set EJECT(OFF).
Next, you have a group of MVC attributes specific to T9840/T9940 media, all with ON/OFF switches:
WARRANTY. VTCS also detects media warranty expiration and sets the WARRANTY status to ON. Alternatively, you can use SMF, LOGREC data, or your MVC and VTV reports to detect MVCs approaching end-of-life and use the MVCMAINT to manually set WARRANTY ON. Knowing that the warranty has expired lets you plan for media replacement before media end-of-life occurs (see the next bullet). What if you know an MVC was erroneously marked as warranty expired? Answer: Just use MVCMAINT to reset the warranty expired status.
RETIRED. VTCS also automatically detects media end-of-life and sets the RETIRED status to ON. As above, you can use SMF, LOGREC data, or your MVC and VTV reports to detect MVCs approaching end-of-life and use the MVCMAINT to manually set RETIRED ON or reset the status to RETIRED OFF for MVCs erroneously marked as retired
VTCS automatically detects an invalid Media Information Region (MIR) and sets the INVLDMIR status to ON. You can recover the MIR by using either the utility available through the operator panel for the transport or by using the utility available through MPST. After you recreate the MIR, you can use the MVCMAINT to set INVLDMIR OFF for the MVC.
Note:
Running MVCMAINT also produces an MVC report of the volumes affected by the MVCMAINT job.The MEDVERify utility does Media Verification (MV) by verifying that VTV data can be read on MVCs or VMVCs (ELS 7.1 and VLE 1.2 and above only). For VLE, MEDVERify ensures that deduplicated VMVCs can be ”rehydrated” (reconstituted).
The utility reports on MVCs that pass or fail verification and also produces XML output. For more information on the MEDVERify utility, see ELS Command, Control Statement, and Utility Reference.
The following sections show examples of using the MEDVERify utility for MV.
MEDVERFY MVC(VMC000)
In this example:
MEDVERify selects a single VMVC.
MAXMVC defaults to 99.
CONMVC defaults to 1 so only a single MVC is processed at a time.
No time out is specified.
MEDVER MVCPOOL(MP1)
In this example:
MEDVERify selects MVCs in MVC Pool MP1 for processing.
FREQency is not specified and MAXMVC defaults to 99, so MEDVERify selects the best 99 MVC candidates based on time of last verification.
CONMVC defaults to 1 so only a single MVC is processed at a time.
No time out is specified.
MEDVER MVC(MVC000-MVC049) CONMVC(2) TIMEOUT(720)
In this example:
MEDVERify selects a range of 50 MVC volsers for processing.
FREQency is not specified and MAXMVC defaults to 99, so MEDVERify processes all 50 specified MVCs.
CONMVC is 2, so MEDVERify processes two MVCs concurrently.
MEDVERify runs for 12 hours before timing out.
MEDVER STORCLAS(SC1) MAXMVC(50) FREQ(365)
In this example:
MEDVERify selects MVCs in Storage Class SC1 for processing.
MAXMVC is 50 and FREQency specifies 365 days, so MEDVERify selects the best 50 MVC candidates that have not been verified for 1 year or more.
CONMVC defaults to 1 so only a single MVC is processed at a time.
No time out is specified.
The main thing you can do, as needed, with VTSSs is use the VTCS Vary VTSS command or utility to vary a VTSS online, offline, or to quiesced state. Always know what you are doing, and why, when you vary a VTSS offline or to quiesced state. The why is probably that the VTSS needs maintenance or you are going to remove it from the configuration, which is talked about in "Finding and Fixing VTCS Problems."
First, however, the following chart shows you what happens when you vary a VTSS into each of its supported modes (and why you should use QUIESCED over OFFline, if at all possible).
| Vary VTSS Parameter Specified | VTSS First State | VTSS Next State |
|---|---|---|
|
ONline |
Online Pending - In online pending state, the online process has started but has not completed on all hosts. |
Online - In online state, the VTSS is online, available, and accepts both front-end and back-end work. If the VTSS was offline, when it goes online, VTCS issues a warning message recommending a VTSS audit. |
|
QUIESCED |
Quiescing - In quiescing state, VTCS does not direct any DD allocation to the VTSS, which still accepts pending mounts to allow those long running jobs with unit=aff chains to complete. When all VTDs are no longer in use (their UCBs are not allocated on MVS), the VTSS goes to quiesced state. In quiescing state, the VTSS continues to accept and process back-end work; for example, migrates, recalls, and audits. |
Quiesced - In quiesced state, the VTSS continues to accept and process back-end work; for example, migrates, recalls, and audits. That is, you can use the recall and migrate commands and utilities to do these operations using the quiesced VTSS. |
|
OFFline |
Offline Pending - In offline pending state, the offline process has started but has not completed on all hosts. VTCS immediately shuts down the VTSS and interrupts and purges all active tasks and purges all queued tasks. The VTSS server task terminates and no longer accepts new front-end and back-end work. VTCS creates new VTVs and mounts/dismounts existing VTVs only on alternate VTSSs, if they are available. |
Offline - In offline state, The VTSS is offline to all hosts and does not accept either front-end or back-end work. If a copy of a VTV is resident on an offline VTSS and also on an MVC and a job requires the VTV, VTCS automatically recalls the VTV to an alternate VTSS, if available. |
Note:
In a client/server environment (MVS/CSC and LibraryStation or SMC/HTTP server on client hosts), VTCS cannot determine if long running jobs are active on client hosts. After a VTSS goes to offline state, therefore, you should still either (a) explicitly vary its VTDs off line to MVS or (b) ensure that virtual tape activity on the client host has ceased.In Clustered VTSS or Cross-TapePlex Replication (CTR) configurations, the Clinks to the VTSS should be varied offline to stop replication and electronic export processing.
Before you service a VTSS, quiesce the VTSS as follows:
On every host vary the VTSS VTDs offline.
On every host wait for all devices to go offline. Note that VTDs do not go through the offline process until they are no longer allocated. If a long running job is using a VTD then you must either wait for the job to complete or cancel the job.
Vary the VTSS QUIESCED from any VTCS system where the named VTSS is defined.
Wait for message SLS6742I on each VTCS system indicating the VTSS is quiesced.
Optionally, you can migrate data from the VTSS.
Vary the VTSS OFFLINE from any VTCS system where the named VTSS is defined.
Wait for message SLS6742I on each VTCS system indicating the VTSS is offline.You can now service the VTSS.
Here is the scenario for removing a VTSS: You have two separate VSM systems, the workload for one grows while the workload diminishes for the other. Solution: take a VTSS out of System A and give it to System B. Installing ELS discusses how to add a VTSS, so this section is confined to what you do to remove a VTSS.
To remove a VTSS:
Before you remove the VTSS, do the following:
You do not need to empty a VTSS before deletion. What you do need to ensure is that all VTVs are fully migrated. Also consider changing other parameters, for example, TAPEREQ statements so that new work is not routed to the removed VTSS.
If removing all of one device type/ACS combination from a VTSS, also ensure that all VTVs are fully migrated first. As above, consider changing other parameters to reflect the changed migration capabilities of the VTSS (for example, Management Classes, which point to Storage Classes that specify ACS and media).
Vary the VTSS to Quiesced state.
After it goes offline, continue with step 3.
Remove the VTSS, then rerun CONFIG to logically remove it.
The following shows sample JCL to run CONFIG to update the configuration to deny host access to VTSS2 that you physically removed from your configuration. In this example, you respecify the VTSS statement for VTSS2 with no parameters to deny host access to this VTSS.
//UPDATECFGEXEC PGM=SLUADMIN,PARM='MIXED' //STEPLIBDD DSN=hlq.SEALINK,DISP=SHR //SLSCNTLDD DSN=FEDB.VSMLMULT.DBASEPRM,DISP=SHR //SLSCNTL2DD DSN=FEDB.VSMLMULT.DBASESEC,DISP=SHR //SLSSTBYDD DSN=FEDB.VSMLMULT.DBASETBY,DISP=SHR //SLSPRINTDD SYSOUT=* //SLSINDD * CONFIG GLOBALMAXVTV=32000MVCFREE=40 RECLAIMTHRESHLD=70MAXMVC=40 START=35 VTSSNAME=VTSS1 LOW=70 HIGH=80 MAXMIG=3 RETAIN=5 RTDNAME=VTS18800 DEVNO=8800 CHANIF=0A RTDNAME=VTS18801 DEVNO=8801 CHANIF=0I RTDNAME=VTS18802 DEVNO=8802 CHANIF=1A RTDNAME=VTS18803 DEVNO=8803 CHANIF=1I RTDNAME=VTS18811 DEVNO=8811 CHANIF=0E RTDNAME=VTS18813 DEVNO=8813 CHANIF=1E VTDLOW=8900 HIGH=893F VTSSNAME=VTSS2
This section consists of the most likely tasks you might have to do on an as-needed basis: deleting scratch VTVs and changing VTV attributes.
Note:
If you delete VTVs from the configuration as a result of either SET VOLPARM or CONFIG MVCVOL processing:You cannot re-enter the volsers into the configuration as MVCs.
Do not use the volsers for native HSC tapes.
Message SLS6944I indicates the number of VTVs that have been deleted.
There are two ways you can delete scratch VTVs:
By policy, by specifying DELSCR(YES) on a VTV's Management Class and using HSC or LCM scratch synchronization to do the actual scratch.
For specific tasks, by using the DELETSCR utility. DELETSCR deletes scratch VTVs from VTSSs and unlinks any migrated VTVs from MVCs. Deleted VTVs are marked as non-initialized, although versioning information is retained.
Installing ELS addresses deleting scratch VTVs, so the information that follows discusses the "as needed" version.
Take note of the following warning:
Caution:
When you use DELETSCR to delete scratch VTVs, any data on those VTVs is gone and cannot be recovered!Deleting VTVs is not something you do because you have nothing else to do. If you have to manually delete scratch VTVs, it is because you are in trouble as shown in the scenario.
To prevent inadvertent VTV deletion through an operator command, DELETSCR is a SLUADMIN utility only, and has the following capabilities:
You can specify VTVs by volser (individual volser, list, or range), Management Class, or HSC Scratch Pool. Using your MVC and VTV reports, you should already have a good idea of the best way to identify the candidates and apply the corresponding DELETSCR option. You can only specify one option (VTVid, MGMTclas, or SCRpool) and if you do not specify anything, DELETSCR deletes all eligible VTVs. This may be what you want, but think before you go for that method.
The mandatory NOTREF parameter specifies the days since a VTV was referenced (1-999). NOTREF is effectively a grace period; any VTV referenced within the specified grace period is not deleted.
There is a handy (optional) MAXVTV parameter that specifies the maximum number of VTVs that DELETSCR deletes. Note that this is a maximum, not a target. If you are running DELETSCR proactively during a non-peak period, you might not care about MAXVTV. If you are in trouble, you most certainly will.
Note that the range for MAXVTV is 0-999. What happens if you specify 0? In this case, DELETSCR does not delete any VTVs, but the summary report shows how many VTVs have been deleted at the point at which you ran DELETSCR (that is, the report is just a snapshot).
Finally, you can see the results of your work through the DELETSCR reports, standard or detailed (by specifying the DETAIL parameter).
The following shows sample JCL to run the DELETSCR to delete scratch VTVs in Management Class MC1 not referenced within 60 days up to a maximum of 800 VTVs and produce a detailed report.
//DELETSCR EXEC PGM=SLUADMIN,PARM='MIXED' //STEPLIBDD DSN=hlq.SEALINK,DISP=SHR //SLSPRINTDD SYSOUT=* //SLSINDD * DELETSCR MGMTCLAS(MC1) NOTREF(60) MAXVTV(800) DET
VTVMAINT is another handy tool, this time for VTV maintenance, which does the following:
Selects VTVs by volser (range, list, or individual volser as you choose).
Unlinks VTVs from MVCs, because it is likely you are going to want to do this if you change a VTV's Management Class as described in "Changing VTV Management Class and Unlinking VTVs from MVCs."
Changes the VTV's Management Class, which you do when you want the VTV to be managed differently. There are other ways to do this, but the best tool is clearly VTVMAINT, as described in "Changing VTV Management Class and Unlinking VTVs from MVCs."
Logically dismounts specified VTVs in an offline VTSS. This is best explained in "Logically Dismounting VTVs in an Offline VTSS."
"Managing VTVs Replicated Through Cross-TapePlex Replication (CTR)."
Note:
And do not forget, running VTVMAINT also produces a VTV report of the volumes affected by the VTVMAINT job.You can use VTVMAINT to change a VTV's Management Class. If the new Management Class specifies a different Storage Class, the VTV's current location on MVCs is incorrect. The following procedure tells how to use VTVMAINT to change a VTV's Management Class and Storage Class.
To change a VTV's Management Class and unlink it:
Recall the VTV.
The VTV must be VTSS-resident for the unlink to succeed in step 2.
Use VTVMAINT ULINKMVC to unlink the VTV from the MVC(s) where it is located.
Use VTVMAINT MGMTclas to assign a new management class.
Remigrate the VTV to place it on the correct MVCs, or see "Changing VTV Storage Class with RECONcil" for procedures for moving VTVs to MVCs as needed.
If a VTV is mounted when a VTSS goes offline and a copy of the VTV exists on an MVC, VTCS does not recall the migrated VTV to an alternate VTSS because the VTV is in mounted status on the offline VTSS. In this situation, you can use the VTVMAINT to logically dismount VTVs in the offline VTSS (turn off the ”mounted” bit in the CDS), then recall the VTV to an alternate VTSS. VTCS records each successful VTV dismount in the SMF14STA field of the SMF Subtype 14 record. The VTVRPT (UNAVAIL) option reports the status of unavailable VTVs in an offline VTSS. For more information, see ELS Command, Control Statement, and Utility Reference.
Do not dismount an unavailable VTV in an offline VTSS unless you are absolutely sure that the MVC copies, if any, of the VTV, are identical in content to the unavailable VTV! Otherwise, you risk recalling a VTV with back-level data to an alternate VTSS! For example, a VTV mounted for read is probably safe to dismount for recall to an alternate VTSS. A VTV mounted for write, however, is probably not safe to dismount because it has probably been updated and the MVC copies are therefore back-level.
The following procedure provides the general steps you use to logically dismount a VTV and access that VTV from a different VTSS.
To logically dismount a VTV and access that VTV from a different VTSS:
Vary the VTSS offline to VTCS with the following command:
VT VARY VTSS(name) OFFLINE
If I/O was active and the VTSS failed, MVS should box the VTDs and dismount any mounted VTVs from the MVS perspective. However, if communication with the VTSS failed before the VTSS actually dismounted any mounted VTVs, they may still be online to VTCS. Therefore, you first need to vary the VTSS offline to VTCS.
If MVS boxed the VTDs and dismounted any mounted VTVs, go to step 3. Otherwise, continue with step 2.
Dismount the VTV (MVS perspective).
You cannot remount the VTV on a VTD in another VTSS if MVS still considers it mounted in the offline VTSS. Do either of the following:
Use the MVS UNLOAD command to dismount the VTV.
Use the VARY OFFLINE to vary offline the VTD where the VTV is mounted, which also dismounts the VTV.
Run VTVMAINT, specifying the offline VTSS and VTV(s) you want to logically dismount.
For example, to logically dismount VTVs VV6823, VV6825, and VV6688 in offline VTSS01, code the following SLSIN DD statement in your JCL:
VTVMAINT DISMOUNT VTV(VV6823,VV6825,VV6688) VTSS(VTSS01)
If migrated copies of the dismounted VTVs exist that an online VTSS can access, you can now use this VTSS to access the VTVs.
Caution:
If the VTV copy mounted in the offline VTSS was modified and not migrated, the MVC copy that you recall to an alternate VTSS is not current! Therefore, Oracle strongly recommends that you do not recall these non-current MVC copies!Tip:
When the offline VTSS is ready to be brought back online, Oracle strongly recommends that you audit the VTSS before running production jobs that use the VTSS. Also ensure that you clear any boxed VTD conditions before issuing the VTSS VARY ONLINE command.You can use VTVMAINT to change the status of VTVs replicated through CTR as follows:
Use VTVMAINT OWNRPLEX to change the VTV's owning TapePlex.
Use VTVMAINT DELEXpot to remove the name of a TapePlex that references a VTV.
Use VTVMAINT ADDEXpot to add the name of a TapePlex that references a VTV.
For more information, see ELS Disaster Recovery and Offsite Data Management Guide.
As described in "Changing VTV Management Class and Unlinking VTVs from MVCs," you can use VTVMAINT to change a VTV's Management Class, which could, of course, change its Storage Class. Or what if you want to explicitly move the VTV from one Storage Class to another? Answer: use RECONcil.
Before you submit your first RECONcil job (SLUADMIN utility only), figure out why you want to change a VTV's Storage Class. There are basically three reasons:
As above, you are explicitly changing the VTV's Management Class/Storage Class.
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.
Notice that this discussion talks about using RECONcil to reconcile a VTV's incorrect Storage Class (incorrect MVC media, ACS location, or both). What if you wanted to move VTVs whose data is now less frequently accessed from access-centric media (such as T9840 cartridges) to storage-centric media (such as T9940 cartridges) and an Extended Store ACS or offsite? In that case, you typically set up an Archive Policy using the ARCHAge/ARCHPol parameters of the MGMTCLAS statement, and the VTV movement then occurs automatically according to the ARCHPol specification when the ARCHAge value is exceeded and when the VTV is recalled and remigrated.
An automatic Archive Policy, therefore, is like an automatic migration. Both happen over time, and time is what you do not have if one or more VTVs are truly in the wrong place. In this case, use RECONcil.
To change VTV ACS/media with RECONcil:
To select the VTVs to validate (that is, Do they need reconciliation or not?), you can specify one of the following RECONcil parameters:
STORclas - Specifies one or more Storage Classes. Here, RECONcil does the following:
Looks up the ACS and media definition for the specified Storage Class(es).
Scans the MVCs currently in the Storage Classes. Does the MVC ACS and media match the Storage Class definition? If not, list the MVCs/VTVs in error.
MVC - Specifies a list or range of MVCs. RECONcil does the following:
Determines the actual ACS and media for the specified MVCs.
Does the actual MVC ACS/media match the Storage Class definition for the MVC? If not, list the MVCs/VTVs in error.
MGMTclas - Specifies one or more Management Classes. RECONcil does the following:
Looks up the ACS and media definition as specified on the MGMTclas MIGpol parameter.
Scans the VTVs currently in the specified Management Classes. Is the VTV on an MVC with ACS/media that matches the MGMTclas MIGpol specification? If not, list the VTVs on the MVCs in error.
VTV - list or range of VTVs. RECONcil does the following:
Determines the Management Class(es) for the specified VTVs.
Looks up the ACS and media definition as specified on the MGMTclas MIGpol parameter.
Scans the VTVs currently in the specified Management Classes. Is the VTV on an MVC with ACS/media that matches the MGMTclas MIGpol specification? If not, list the VTVs on the MVCs in error.
Note:
And as you can imagine, if you do not specify any of the selection parameters, VTCS validates all VTVs. More information about this appears in step 2.Accept the default when you first run RECONcil, which is to generate a report only, as you can imagine, does no data movement, but merely reports the VTVs that are candidates for reconciliation.
Caution:
Because reconciling VTVs can be resource intensive, Oracle strongly recommends that you run RECONcil without MOVEVTV first, then adjust the job as needed before specifying MOVEVTV!If needed, adjust the RECONcil job.
For example, if you ran the report in step 2, and it looks like you will be reconciling for a long time, consider doing the following:
Run RECONcil during non-peak processing periods, just as you would a demand MVC space reclamation.
Use the RECONcil utility parameters to override the CONFIG RECLAIM THRESHLD, MAXMVC, and CONMVC settings to optimize reconcile performance.
Specify the maximum time for the reconcile in minutes on the ELAPSE parameter.
Note:
There are multiple 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.There is also a RECONcil POLICYdd option that is also available on the ARCHive utility and can be a useful diagnostic. POLICYdd, which enforces producing only a report, points to a file that contains an alternate set of MGMTclas statements.
Tip:
This is basically a valuable ”what if” tool that says if you changed some VTV Management Classes discussed in "Changing VTV Management Class and Unlinking VTVs from MVCs" (including their Storage Class specifications) and then ran RECONcil, what does that look like? Now you can find out before you actually change a VTV's Management Class.Note:
VTCS and HSC must be active to process a RECONcil request except when you specify the POLICYdd parameter.You have done all the ”what ifs,” fine tuning, and off-peak schedule required.
Now it is time to make it happen. The following shows example JCL to run RECONcil:
Reconcile VTVs in Management Classes LOCALPROD1 and LOCALPROD2.
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 (LOCALPROD1,LOCALPROD2) MAXMVC(60) CONMVC(8) ELAPSE(360) MOVEVTV
And, of course, you get an after-action RECONcil report that tells you how smoothly (or not) things went so you can readjust and rerun the process if necessary.
You can use the LOGUTIL FOR_LOSTMVC statement to recover VTVs that resided on lost or damaged MVCs. How does the LOGUTIL FOR_LOSTMVC statement work and how do you use it most effectively?
The FOR_LOSTMVC utility scans the CDS and the log file structure (if necessary) to identify all VTVs on the lost or damaged MVCs whose volsers you specify and to determine the recovery method from an alternate VTV copy as described in Table 5-2. LOGUTIL FOR_LOSTMVC generates a report showing all VTVs that existed on the lost or damaged MVCs and how they are recovered, plus summary information for each lost or damaged MVC.
Table 5-2 Alternate VTV Copy and Recovery Process
| Alternate VTV Copy Category | Recovery Process |
|---|---|
|
Category 1: Currently VTSS resident. |
Recovery is from the resident copy. If you requested recovery commands, |
|
Category 2: Currently linked to one or more alternate MVC copies. |
Recovery is from the best alternate MVC based on four factors:
If you requested recovery commands, |
|
Category 3: Has been Cross TapePlex Replicated. |
The first remote TapePlex encountered that contains a copy of the VTV is used to recover the VTV. If you requested recovery commands, |
|
Category 4: Was previously linked to one or more MVC copies that may still contain the VTV data. |
One of the previously linked MVCs is selected as the recovery MVC. These MVC copies were found in the log files and may still contain a copy of the VTV. You must audit the selected recovery MVC. The best previously linked MVC copy to do the recovery from is selected based on the same factors as alternate MVCs. If you requested recovery commands,
|
|
Category 5: Is unrecoverable. |
Unrecoverable, copies only existed on the lost or damaged MVCs. |
Note:
If you requested recovery commands,MVCMAINT commands are also generated for Categories 1, 2, and 3, and 4. These statements mark the lost or damaged MVCs as readonly and broken so that they are no longer selected for recalls or migrates.Note:
In this procedure, the JCL examples do not show DD statements for the CDS copies, which is valid if HSC is active and you want to use the active CDS on the system where you are running LOGUTIL. Otherwise, you must specify the DD statements for the CDS copies.To recover VTVs using FOR_LOSTMVC:
First, run the LOGUTIL FOR_LOSTMVC command with only the volsers of the lost or damaged MVCs.
For example, the following example shows:
The logging data set is LOGIN.
Note:
You can runLOGUTIL FOR_LOSTMVC with a dummy LOGDD specified to allow recovery on systems where CDS Logging has not been activated. The recovery is limited to the data in the CDS but may still be useful if all VTVs are either resident, on an alternate MVC copy or exported through Cross Tape Replication.The volser of the damaged MVC is DMV509.
The recovery commands are logged in data set RECVCMD.
//JOBLOGR job (account),programmer,REGION=1024k //S1 EXEC PGM=SLUADMIN,PARM=MIXED //STEPLIB DD DSN=hlq.SEALINK,DISP=SHR //LOGIN DD DSN=FEDB.VSMLMULT.LOGFILE.OFFLOAD(-2),DISP=OLD // DD DSN=FEDB.VSMLMULT.LOGFILE.OFFLOAD(-1),DISP=OLD // DD DSN=FEDB.VSMLMULT.LOGFILE.OFFLOAD(0),DISP=OLD //RECVCMD DD DSN=FEDB.VSMLMULT.RECVCMD,DISP=(CATLG,DELETE), // UNIT=SYSDA,SPACE=(CYL,(1,1),RLSE), // DCB=(RECFM=FB,LRECL=80,BLKSIZE=27920) //SLSPRINT DD SYSOUT=* //SLSIN DD * LOGUTIL LOGDD(LOGIN) FOR_LOSTMVC MVC(DMV509) COMMANDS(RECVCMD)
Review the LOGUTIL FOR_LOSTMVC report from step 1.
Select the VTVs you want to recover and rerun LOGUTIL FOR_LOSTMVC, specifying the VTVs you want to recover from the lost or damaged MVC. For example:
//JOBLOGR job (account),programmer,REGION=1024k //S1 EXEC PGM=SLUADMIN,PARM=MIXED //STEPLIB DD DSN=hlq.SEALINK,DISP=SHR //LOGIN DD DSN=FEDB.VSMLMULT.LOGFILE.OFFLOAD(-2),DISP=OLD // DD DSN=FEDB.VSMLMULT.LOGFILE.OFFLOAD(-1),DISP=OLD // DD DSN=FEDB.VSMLMULT.LOGFILE.OFFLOAD(0),DISP=OLD //RECVCMD DD DSN=FEDB.VSMLMULT.RECVCMD,DISP=(CATLG,DELETE), // UNIT=SYSDA,SPACE=(CYL,(1,1),RLSE), // DCB=(RECFM=FB,LRECL=80,BLKSIZE=27920) //SLSPRINT DD SYSOUT=* //SLSIN DD * LOGUTIL LOGDD(LOGIN) FOR_LOSTMVC MVC(DMV509) VTV(DX009) COMMANDS(RECVCMD)
Note:
If you specify a VTV that was not on the lost or damaged MVC, this VTV is ignored.If you want to recover all specified VTVs on the damaged MVC, continue with step 3.
To recover the specified VTV(s), run the commands in the recovery data set specified in step 2.
Note:
The commands in the recovery data set should be run (using standard SLUADMIN JCL) as soon as possible after running FOR_LOSTMVC to ensure their accuracy.
Oracle recommends that you run the recovery commands in the COMMANDS file in the following order:
All EEXPORT ULINKMVC commands.
All MVCMAINT READONLY(ON) commands.
All AUDIT commands.
If there were EEXPORT ULINKMVC or AUDIT commands, then re-run FOR_LOSTMVC. With the new run, there should be no EEXPORT or AUDIT commands in the newly generated COMMANDS file. If there are, then return to step a.
All MVCMAINT READONLY(ON) ERROR(ON) commands.
All ULINKMVC commands.
All RECALL commands.
The RECONcil utility
MVCMAINT commands are generated for all specified lost or damaged MVCs that exist in the CDS and that have at least one qualifying VTV on them. The MVCMAINT commands set the readonly and error/broken bits on for the lost or damaged MVCs to prevent them from being allocated for recalls or migrates. A maximum of approximately 3000 MVCs is included on each MVCMAINT command.
Run the RECONcil utility to ensure the correct number of MVC copies are created for each VTV.
For example:
//JOBLOGR job (account),programmer,REGION=1024k //S1 EXEC PGM=SLUADMIN,PARM=MIXED //STEPLIB DD DSN=hlq.SEALINK,DISP=SHR //LOGIN DD DSN=FEDB.VSMLMULT.LOGFILE.OFFLOAD(-2),DISP=OLD // DD DSN=FEDB.VSMLMULT.LOGFILE.OFFLOAD(-1),DISP=OLD // DD DSN=FEDB.VSMLMULT.LOGFILE.OFFLOAD(0),DISP=OLD //RECVCMD DD DSN=FEDB.VSMLMULT.RECVCMD,DISP=(CATLG,DELETE), // UNIT=SYSDA,SPACE=(CYL,(1,1),RLSE), // DCB=(RECFM=FB,LRECL=80,BLKSIZE=27920) //SLSPRINT DD SYSOUT=* //SLSIN DD * RECONCIL VTV(DX009)