CA Vtape uses VSAM Linear Data Sets (LDSs) to represent Virtual Volumes. Two types of cache management are provided:
Dynamic is the newest way to manage the LDSs, introduced in r11.5. When Dynamic Cache Management is active, CA Vtape dynamically defines a cache LDS when it is needed. SMS controls the allocation of the LDS. The LDS can be idle-space released, take secondary extents, and span to additional DASD volumes. A single LDS is defined for a Virtual Volume and the data set name of the LDS contains the Virtual VOLSER. The final size of the LDS is essentially determined by the amount of application data written to the Virtual Volume or the defined maximum Virtual Volume Size.
A Cache Monitor periodically scans the SMS storage group or groups and deletes externalized Virtual Volumes to maintain a certain percentage of free space. The percentage of free space is defined by you in the CA Vtape parmlib. The monitor also automatically releases and holds the Externalization Subgroup Queues based on customizable parmlib attributes.
The dynamic LDSs are accessed using SMS Media Manager. Media Manager reduces the amount of CPU used by CA Vtape for data movement by 50%. Media Manager also provides 50% higher throughput.
With Dynamic Cache Management multiple Virtual Volume Pools can be defined and each pool can have its own Virtual Volume Size defined of 400, 800, 2000, 4000, 8000, or 16000 MBs.
The original way to manage the LDSs is referred to as Static Cache Management. The cache LDSs are predefined and initialized to the same size and added to CA Vtape with batch jobs built by the ISPF Customization Process. Each LDS is 1/10th the size of the uncompressed capacity of the Virtual Volume Size you choose during the ISPF Customization Process. SMS management is optional. The LDSs cannot be idle-spaced released, cannot take secondary extents, and cannot be spanned to additional DASD volumes. From one to ten of these LDSs make up one Virtual Volume depending on the amount of application data written. To determine which Virtual VOLSER resides in which static LDS, you must run a batch report.
The Cache Monitor only automatically releases and holds the Externalization Subgroup Queues. The cache is not monitored for free space because the LDSs are never deleted; they are reassigned to a new VOLSER and reused.
The static LDSs are accessed using Data-In-Virtual (DIV). DIV provides good performance, but is CPU-intensive.
Static Cache Management does not support subpooling of the Virtual Volumes and those volume must be defined as 400, 800, or 2000 MBs.
The following table shows a comparison of Static and Dynamic characteristics at a glance:
|
Characteristics |
Static |
Dynamic |
|---|---|---|
|
Access Technique |
DIV |
Media Manager |
|
CPU Usage |
50% higher than Media Manager |
50% less than DIV |
|
Throughput |
50% less than Media Manager |
50% higher than DIV |
|
DFSMS Managed |
Your choice |
Required |
|
Cache LDS Allocation Method |
Predefined and initialized with batch jobs |
Defined as needed |
|
Idle-Space Released |
No |
Yes |
|
Secondary Extents |
No |
Yes |
|
Span DASD Volumes |
No |
Yes |
|
Cache Monitor |
Reassigns LDSs during mount and recall processing |
Maintains free space for immediate allocation |
|
Virtual Volume Subpooling |
No |
Up to eight subpools |
|
Virtual Volume Size |
400, 800, or 200 MBs; only one size per Subsystem |
400, 800, 2000, 4000, 8000, and 16000 MBs; each defined pool can be defined with a different size |
|
LDS Size |
All are 40 or 80 or 200 MBs |
Varies from 12 to 2000 MBs as needed |
|
LDSs per Virtual Volume |
1-10 |
1 |
|
VOLSER in LDS name |
No |
Yes |
Important! We highly recommend you use Dynamic Cache Management.
|
Copyright © 2013 CA Technologies.
All rights reserved.
|
|