Undo DASD cache expansion and reclaim volumes
Article ID: 107887
Updated On:
Products
Vtape Virtual Tape System
Issue/Introduction
What is the process to undo a DASD Cache expansion and regain the volumes used?
Environment
Release:
Component: VTAPE
Component: VTAPE
Resolution
As for how hard it is to get cache back, it depends. Vtape has four types of
data sets that could end up in the cache:
1) Virtual Volume data sets -- prefix.VVE.Vvolser.MM.CACHE.
2) Virtual Device work data sets -- prefix.VVE.Vdevnum.Ssystem.
3) Data queue data set -- prefix.VVE.VDATAQ...
4) If the Tasklib parameter is set to automatic, a special loadlib --
prefix.Ddate.Ttime.LIBn.
The Virtual Volume data sets can be moved with any standard data mover
like ADRDSSU, FDR, CA Disk, etc. Vtape does not have any location specific
information concerning these data sets in its control data sets. When one
of these data sets is needed, Vtape requests its location from the catalog.
The only time these data sets are enqueued is when there is a mount being
serviced for the Virtual VOLSER whose data is in one of these data sets.
If the only data sets on the cache DASD volumes you want to remove from
cache are these data sets, you just update SMS to put the required volumes
into DISNEW status and then run your data mover of choice to copy these
data sets to other volumes. When the volumes are empty, remove them from
the SMS storage group and repurpose them.
The Virtual Device work data sets are enqueued while Vtape is active.
The only way you can move these guys is with something like IBMS TDMF which
will move them and then dynamically switch the volumes otherwise you have
to stop Vtape.
Once Vtape is stopped, you do not have to copy them. They are just work
data sets with nothing permanent in them, so just delete them. When Vtape is
restarted, it will check the catalog for them, find they do not exist and
dynamically define a new one. If you update your ACS routines to send these
guys to work packs or system packs, then you will not have to worry about
moving them or deleting them and letting Vtape define them again.
There is one of these for each Virtual Device so corralling them onto
one DASD volumes is not a good idea.
The VDATAQ data set is used to hold work in progress across stops and
starts or IPLs. If the work is not completely, it will be restarted where
it left off. This data set is also enqueue while Vtape is active and cannot
be moved unless you use something like IBM's TDMF.
Also, like the Virtual Device data sets, if you stop Vtape and delete
the VDATAQ data sets, Vtape will just define a new one when restarted.
If you add code to your ACS routines to send this guy to a work pack or
a system pack, it might make your life easier when performing DASD evolutions
in the future.
data sets that could end up in the cache:
1) Virtual Volume data sets -- prefix.VVE.Vvolser.MM.CACHE.
2) Virtual Device work data sets -- prefix.VVE.Vdevnum.Ssystem.
3) Data queue data set -- prefix.VVE.VDATAQ...
4) If the Tasklib parameter is set to automatic, a special loadlib --
prefix.Ddate.Ttime.LIBn.
The Virtual Volume data sets can be moved with any standard data mover
like ADRDSSU, FDR, CA Disk, etc. Vtape does not have any location specific
information concerning these data sets in its control data sets. When one
of these data sets is needed, Vtape requests its location from the catalog.
The only time these data sets are enqueued is when there is a mount being
serviced for the Virtual VOLSER whose data is in one of these data sets.
If the only data sets on the cache DASD volumes you want to remove from
cache are these data sets, you just update SMS to put the required volumes
into DISNEW status and then run your data mover of choice to copy these
data sets to other volumes. When the volumes are empty, remove them from
the SMS storage group and repurpose them.
The Virtual Device work data sets are enqueued while Vtape is active.
The only way you can move these guys is with something like IBMS TDMF which
will move them and then dynamically switch the volumes otherwise you have
to stop Vtape.
Once Vtape is stopped, you do not have to copy them. They are just work
data sets with nothing permanent in them, so just delete them. When Vtape is
restarted, it will check the catalog for them, find they do not exist and
dynamically define a new one. If you update your ACS routines to send these
guys to work packs or system packs, then you will not have to worry about
moving them or deleting them and letting Vtape define them again.
There is one of these for each Virtual Device so corralling them onto
one DASD volumes is not a good idea.
The VDATAQ data set is used to hold work in progress across stops and
starts or IPLs. If the work is not completely, it will be restarted where
it left off. This data set is also enqueue while Vtape is active and cannot
be moved unless you use something like IBM's TDMF.
Also, like the Virtual Device data sets, if you stop Vtape and delete
the VDATAQ data sets, Vtape will just define a new one when restarted.
If you add code to your ACS routines to send this guy to a work pack or
a system pack, it might make your life easier when performing DASD evolutions
in the future.
Feedback
Yes
No
Powered by
