|
VTS
DataKinetics VTS is a performance enhancement product for tableBASE. It allows applications running in different regions or operating environments (CICS, batch, TSO, DB2, etc.) to access table data contained within a shared common memory pool. Many applications, one copy of the data.
This means that all common data can be accessed at memory speed from the shared VTS-TSR, and the local TSR no longer has to contain common data. Also, since there is only one copy of the data, all regions are guaranteed to be using the same data. In this way, I/O, real memory and system paging usage are all dramatically reduced.
 Shared Data Spaces
|
|
Parallel Processing
While tableBASE by itself dramatically improves mainframe transaction throughput, significant performance enhancements can be further obtained by leveraging multiple CICS and/or IMS regions to run in parallel. Several regions processing transactions provide more throughput than a single region. However, all these regions will use their own memory, and consume their own caching resources. And if they all initialize simultaneously, there could be a serious bottleneck situation, as all regions attempt to load their tables from a single load source.
DataKinetics VTS shared in-memory tables
VTS allows many regions to share in-memory tables. Where 50 regions would use a significant amount of real and cache memory resources, VTS allows you to consume 1/50th of the resources, while enjoying the increased throughput of those 50 regions. Reaping all the benefits, suffering from none of the drawbacks. |
Figure 1: Duplicated Data (top) Shared Data (bottom) |
|
|
Improved Load-Time Performance
|
|
Performance issues when over-taxing the local TSR
In some instances, as demand for data access increases, and tableBASE usage increases, customers can experience increased performance issues at initialization-time. Consider the scenario in Figure 2, where a large number of tables are loaded into a single TSR from multiple libraries.
At initialization, data is loaded from tableBASE libraries into the local TSR row-by-row, with associated indexes being constructed for each table. This is a very I/O intensive process, and can be a quite time-consuming, particularly if there are a large number of tables being loaded from a large number of libraries, as is the case shown here.
VTS Improves Load-Time Performance
The tableBASE VTS option can dramatically improve performance during initialization time. This is accomplished using a shared TSR, known as a VTS-TSR. Consider the same scenario as before, but this time using a shared VTS-TSR in addition to the local TSR (see Figure 3).
This divides the burden between two TSRs, rather than housing all tables within a single TSR. Access to tables is more efficient if there are fewer tables in a given TSR.
At initialization, the amount of time, CPU and I/O activity required to load data from the tableBASE libraries into the local TSR can be reduced considerably. This translates into sharply lowered initialization times for the local TSR. The shared VTS-TSR is loaded with table data once and is left running-tables can be reloaded without taking down the entire TSR. |
Figure 2: Duplicated Data (top)
Shared Data (bottom)
Figure 3: Duplicated Data (top)
Shared Data (bottom) |
|
|
Improved Run-Time Performance
|
|
As demand for data access increases, and tableBASE usage increases, customers can experience increased performance issues during run-time. Consider the scenario shown in Figure 4, where the local TSR is burdened with many tables, causing ongoing access congestion.
VTS Improves Run-Time Performance
You can dramatically improve performance during run time, by using a shared VTS-TSR. Consider the same scenario as before, but this time using a shared VTS-TSR in addition to the local TSR (see Figure 5).
During run-time, space is freed-up in the local TSR; it no longer has to serve as a data repository for all tables. Accessing data from an uncluttered TSR is far more efficient that accessing data from a congested TSR.
The VTS-TSR is as a very efficient and independent in-memory repository, and is the best place to store common data. It outlives the applications that use it-and it can be started, initialized and populated with data tables, completely independently of the applications that use the data. |
Figure 4: Duplicated Data (top)
Shared Data (bottom)
Figure 5: Duplicated Data (top)
Shared Data (bottom) |
|
|
Secured Data Availability
|
|
When separate regions use dedicated TSRs, any catastrophic shut down of the region can result in lost data. With DataKinetics VTS, the VTS-TSR-based data outlives the accessing regions. Also, no applications can update or corrupt the tableBASE library. Updates to the library can be isolated and externalized.
|
|
Related Products
|
|
DataKinetics VTS is an add-on product for tableBASE. VTS is also a required component for the Process Manager product. Along with tableBASE and Process Manager, VTS forms the basis for DataKinetics solutions for a variety of business issues including multi-LPAR operation, the optimization of Java access to mainframe data, and others.
|
|
Read More
|
For further information about VTS and other DataKinetics products:
|
|
