Various questions on using Vtape DASD cache and having all Vtape data recalled into cache
Article ID: 236661
Updated On:
Products
Issue/Introduction
Q1. Is there any limit on maximum disk volumes for the Vtape cache ?
Q2. Is there a limit on maximum size of the Vtape cache (DASD buffer) ?
Q3. I want to recall all my virtual volumes so that they are in the Vtape cache (DASD buffer)
q3a. How can I be sure that there will be no cleanup of these volumes (i.e., deletion of the externalized tape data)?
q3b. What if Vtape auto externalization is turned OFF (the various Vtape threshold parameters are set to 0)? Is there any impact?
q3c. If my DASD cache becomes full, what will happen next ?
q3d. If I recall all of my virtual volumes, are there any performance problems?
q3e. How can I recall all volumes (can I do this by dataset name or by physical or virtual tape)?
q3f. Is it possible to have all recalled data protected so that it is not overlaid with other data?
Environment
Release : 12.6
Component : VTAPE
Resolution
Q1. Is there any limit on maximum disk volumes for the Vtape cache ?
Answer: There is a limit of 59 DASD volumes which can be used for the Vtape cache. This is set via the SMS Data Class definition in the field 'Dynamic Volume Count'. This is a SMS limitation, not a Vtape limitation per se.
Q2. Is there a limit on maximum size of the Vtape cache (DASD buffer) ?
Answer: There is no direct or specific limit on the total size of the Vtape case (except for the DASD volume count limitation described above).
Q3. I want to recall all my virtual volumes so that they are in the Vtape cache (DASD buffer)
q3a. How can I be sure that there will be no cleanup of these volumes (i.e., deletion of the externalized tape data)
Answer: If you recall all virtual volumes from the backstore tapes, they will then reside in the Vtape cache. If the virtual volumes eventually contain all expired data sets, then these virtual volumes could become eligible to be scratched (such as via CA1 TMSCLEAN processing). The externalized (backstore) tapes won't be deleted per se, but if Vtape RECYCLE processing is performed, virtual volumes on one physical tape may be moved to another physical tape, and once the original physical tape doesn't contain any active virtual volumes/data on it, then it could become eligible to be scratched (but there won't be any loss of Vtape data as this data may have either been migrated to other physical volumes, or else all of the data of the virtual volumes has expired, and then these virtual volumes could then become scratched).
q3b. What if Vtape auto externalization is turned OFF (the various Vtape threshold parameters are set to 0)? Is there any impact?
Answer: You can turn off externalization so that nothing gets backstored. This will only have impact if new data is created, but has not been backstored yet, and the cache becomes full with other virtual volume data that has been RECALLed into Vtape cache. If the cache usage reaches a pre-defined threshold, then the user will get warning messages indicating a Vtape cache shortage exists (and it is assumed that the user would then release the affected GROUP queues to externalize the new data so that it can free up some of the cache). Note that if the cache contains a lot of previously backstored data that was recalled into Vtape cache, and this data was NOT modified after being placed in cache, this data could be overlaid with new data that is created (the reason this is allowed is that Vtape 'knows' that it already has a copy of this *unmodified* data on physical tape, and thus if it needs to be recalled back into cache for processing, it can successfully do this. If the data is *new*, it cannot allow this as Vtape has no way to recall this data. New data needs to be backstored first before Vtape will allow this data to be overlaid with other virtual volume data, such as via RECALL). Also, note that if Vtape cache contains previously backstored data, this data could get overlaid with other previously backstored and recalled data (Vtape tries to keep the most recently referenced data in cache, and allow older backstored cache to be overlaid, as needed).
q3c. If my DASD cache becomes full, what will happen next ?
Answer: You will get warning messages about the cache shortage threshold being reached, thus prompting the user to release some of the Vtape groups/queues for backstoring the data, thus freeing up some of the cache space for new (or 'old' recalled) data.
q3d. If I recall all of my virtual volumes, are there any performance problems?
Answer: There aren't any performance problems per se, but of course if you have a lot of data to recall, it will take time for the physical tape mounts to take place to then read the data into cache. The Vtape MAXDRIVES parameter can be set to a higher value to allow more physical drives to be allocated concurrently, thus possibly improving RECALL processing.
q3e. How can I recall all volumes (can I do this by dataset name or by physical or virtual tape)?
Answer: There is a special job which is shipped with the Vtape product which can help with recalling many volumes. You can find this job in the Vtape data set: **.CCUUJCL(RCALMANY)
q3f. Is it possible to have all recalled data protected so that it is not overlaid with other data?
Answer: Vtape will overlay volumes in cache if there isn't enough storage to accommodate either new data being created, or old data being recalled from backstore physical tapes. If there isn't enough cache storage to hold all RECALL data plus NEW data, then the NEW data will take precedence and overwrite the 'old' (previously backstored) data. Now, if you have plenty of cache storage to hold everything (old plus new data), then at least in theory, you shouldn't have a problem with overlaying of data, but there is a method to better guarantee this, and that would be to read in the 'old' data into cache, then do a copy of the virtual volumes to new virtual volumes, but this 'copy' of data would be directed to a Vtape group with the 'CACHONLY' attribute set, thus this 'new' copied data would be protected from being overlaid. The main downside to this though, is that when the new data is created and re-cataloged (assuming the original data is cataloged), there is the potential that the virtual volume references to the 'old' data on backstore tape could be lost when TMSCLEAN/scratch processing is done (the old volume entries could be marked as expired if TMSCTLG is run, because it is seen that the original volumes are not cataloged any more, thus making the old volumes eligible to be scratched). In this case, if for some reason you needed to re-process the backstore data, Vtape would not be able to find the data on physical tape since the 'VVE' catalog entries would have been scratched.
Some Vtape doc references:
Setting Up Dynamic Cache Management in SMS:
https://techdocs.broadcom.com/us/en/ca-mainframe-software/traditional-management/ca-vtape-virtual-tape-system/12-6/configuring/cache-management/dynamic-cache-management/setting-up-dynamic-cache-management-in-sms.html
DYNAMIC OPTIONS:
https://techdocs.broadcom.com/us/en/ca-mainframe-software/traditional-management/ca-vtape-virtual-tape-system/12-6/configuring/the-parameter-library-parmlib/vtparms-parmlib-member/dynamic-options.html
Additional Information
Some Vtape doc references:
Setting Up Dynamic Cache Management in SMS:
https://techdocs.broadcom.com/us/en/ca-mainframe-software/traditional-management/ca-vtape-virtual-tape-system/12-6/configuring/cache-management/dynamic-cache-management/setting-up-dynamic-cache-management-in-sms.html
DYNAMIC OPTIONS:
https://techdocs.broadcom.com/us/en/ca-mainframe-software/traditional-management/ca-vtape-virtual-tape-system/12-6/configuring/the-parameter-library-parmlib/vtparms-parmlib-member/dynamic-options.html
Feedback
