2 How Does ELS Work?

This chapter tells how ELS works.

How Does SMC Work?

SMC does the following:

  • Influences tape allocation based on policies, and on volume and drive characteristics supplied by HSC/VTCS:

    For example, the SMC POLICY command can be used to direct scratch allocations to either real or virtual devices, can select scratch subpools, and can assign a management class name that VTCS uses to manage virtual volumes.

  • Intercepts MVS mount, dismount, and swap messages and directs them to HSC or VTCS for automation.

SMC must execute on every host where tape processing occurs. The ELS server component (HSC/VTCS) may execute on the same z/OS host as the SMC, or may execute on a separate, remote host. When SMC and HSC/VTCS reside on different z/OS hosts, TCP/IP is used to send requests from the client host to the server host. In order to receive HTTP requests from a remote SMC client, the HTTP component must be activated on the SMC executing on the server host.

The SMC client/server feature lets you run SMC only on the client hosts and HSC/VTCS and the HTTP server on one or more server hosts. Using the SMC client/server feature provides the following benefits:

  • Reduces the number of hosts on which you run HSC/VTCS. Oracle recommends that you execute HSC/VTCS on only two hosts (primary and backup). Running HSC/VTCS on fewer hosts reduces CDS contention and eliminates the need to manage multiple MVS syslog files.

  • Communicates with multiple HSC/VTCS TapePlex systems representing physically different hardware configurations.

  • Provides failover capabilities when an HSC is recycled for maintenance.

How Does HSC Work?

HSC controls the physical tape environment. HSC, responding to requests from SMC, directs an LSM robot or handbot to mount and dismount physical tapes. HSC controls all other physical tape operations as well, including moves, swaps, and so forth. HSC also manages the CDS (Control Data Set) where information about the real and virtual tape environments is stored.

How Does VTCS Work?

The VTSS provides Virtual Tape Drives (VTDs) that emulate 3490E devices. VSM uses the VTDs to write data to virtual tape volumes (VTVs) on the VTSS.

VTCS is the software that controls the VTSS hardware. For example, you specify the VTSS's high and low Automatic Migration Thresholds (AMTs), which control the VTSS space management/VTV migration cycle. Real tape drives (RTDs) write migrated VTVs to physical multi-volume cartridges (MVCs). VTCS controls RTDs (although HSC provides mount and dismount services for MVCs), while HSC controls ACS tape drives that are not allocated to VSM.

If the host requests a mount of a VTV that was migrated to an MVC and is not VTSS–resident, VSM automatically recalls the migrated VTV to the VTSS. Figure 2-1 shows the VTV migration/recall cycle.

Note:

VSM supports dynamic sharing of RTDs between VTSSs. However, when VTSSs share RTDs, the VTSSs must have access to all the same hosts.

Figure 2-1 VTV Migration/Recall Cycle

Surrounding text describes Figure 2-1 .

  1. Migration — virtual mount data set written to VTV, virtual dismount of VTV resident on VTSS, VTV is collected with other VTVs, real mount of VTV stacked on MVC, and real dismount.

  2. Recall — real mount for recall of VTV, VTV recalled to VTSS, and virtual mount.

How Does CDRT Work?

CDRT creates a test copy of the production CDS that is used by the DR hosts and therefore allows two ELS subsystems with two different CDSs to manage the same ACS hardware. The CDS reflects changes in the state of tape cartridges and resources in the ACS hardware. However, during a DR test using CDRT, the two ELS subsystems use two different CDSs, and do not communicate. Thus changes that occur in the production CDS are not reflected in the test CDS copy and visa versa. CDRT acts to segregate the test ACS and VSM hardware from the production ACS and VSM hardware, managing the DR test to ensure the integrity of the production data and minimizing conflicts for tape volumes and ACS hardware resources. Central and fundamental to a successful DR test using CDRT is a valid point-in-time copy of the state of all tape volumes managed by ACS and/or VSM hardware and the ELS subsystem. In a tape volume environment, quite often some of this tape volume state data (metadata) is retained and managed outside of the ELS subsystem and ACS/VSM hardware. Typically, tape volume metadata (i.e. VOLSER, DSN, Expiration date, scratch status, real or virtual designation, etc.) is stored in one or more Tape Management Catalogs (TMCs), one or more z/OS catalogs and the CDS. Ensuring that the state of tape volumes as reflected on host systems is either the same or equivalent on both production hosts and DR hosts, is critical to successful execution of a DR test. This consistency in the state of tape volumes between the production hosts and the DR hosts at the start of the DR test is what allows the parallel processing of customer applications to assist in validating a business continuance plan. The DR test hosts exercise the segregated hardware while production hosts continue using both the non-segregated and segregated ACS hardware.

The DR test hardware is a minimum of one ACS. Optionally, one or more VTSSs may be employed as DR test hardware. The ACS is shared between the production hosts and the DR hosts. The DR hosts have exclusive use of any segregated VTSSs during the DR test. To produce valid point-in-time copies of any TMCs and z/OS catalogs, see the appropriate 3rd party software documentation. At the end of a DR test, all data created from the DR test hosts, including the test copy of the CDS is typically discarded and the segregated hardware is redeployed back to the normal production environment