More options with VTS

While the solution shown above is a powerful response to the performance problems of the described scenario, there are still more possibilities offered by VTS.

No tables in local TSR

There are some advantages in relocating all tableBASE table data into a VTS-TSR. This solution allows very fast application initialization—no tables have to be loaded into the local TSR, all data stays in the VTS-TSR, which is independent of application initialization and shut-down.

Figure 75. No tableBASE data in local TSR
No tableBASE data in local TSR

Another advantage is that the application is completely isolated from the data, making the data impervious to application corruption or failure.

Multiple application environment

There are some advantages in accessing tableBASE data from multiple applications. First, VTS has inherent compatibility features that allow access from multiple environments simultaneously, allowing for diversified applications.

Figure 76. Multiple applications accessing shared tableBASE data
Multiple applications accessing shared tableBASE data

Applications from different regions (e.g., CICS/TS, batch, IMS/TM, etc.) can access the same shared data within a VTS-TSR. Second, cloned applications in multiple address spaces can access the same shared data, avoiding application transaction limitations, and increasing overall system throughput.

Multiple VTS-TSRs

It is possible to use multiple VTS-TSRs to further limit access congestion (recall that access to tables is more efficient if there are fewer tables in a given TSR).

Figure 77. Multiple VTS-TSRs
More VTS solutions

By combining solutions (see Figure 78), one group of applications can access a common VTS-TSR, while another group of applications can access a second common VTS-TSR. In this way, access traffic in one application group does not affect the performance of the second application group.

Figure 78. More VTS solutions
More VTS solutions

Read-only tables provide faster access than read-write tables due to the shared locked mechanism. To take advantage of this, all read-only tables can be located in one shared VTS-TSR, while all read/write tables can be located in another. In this way, accesses to the read-only tables will not be affected by updates, which will significantly improve access performance for the read-only tables, for all accessing applications.