3 SMC and StorageTek TapePlex Management

SMC includes several facilities used to configure and manage your StorageTek TapePlex environment, and may be configured on a shared host, or on multiple hosts using the SMC client/server feature.

SMC and the Library Control Server

SMC provides the interface between IBM's z/OS operating system and StorageTek library control systems, HSC and MVS/CSC. SMC can operate with these library control systems in the following ways.

SMC can operate directly with HSC on the same host, or remotely with an HSC on a different host, using TCP/IP and the SMC HTTP server component.
SMC can operate with MVS/CSC on the same host to communicate with ACSLS.

Note:

MVS/CSC 7.1 and later is not compatible with StorageTek LibraryStation. In an MVS-only environment, you must use StorageTek SMC and its HTTP server component to provide communication between MVS hosts.

Defining TapePlexes for SMC

A TapePlex is a single StorageTek hardware configuration, normally represented by a single HSC Control Data Set (CDS). A TapePlex may contain multiple Automated Cartridge Systems (ACSs) and Virtual Tape Storage Subsystems (VTSSs).

It is recommended that you use the SMC TAPEPlex command to explicitly define all tapeplexes to be accessed by an SMC subsystem.

Refer to the ELS Command, Control Statement and Utility Reference for more information about the SMC TAPEPlex command.

Using the SMC Client/Server Feature

The SMC Client/Server feature allows SMC to communicate with HSC systems that are not on the same host as the SMC. This feature enables you to do the following:

Reduce the number of hosts on which HSC is started.

It is recommended that you execute HSC on only two hosts, with the second as a backup. Executing HSC on only one or two hosts reduces CDS contention and eliminates the need to manage multiple MVS syslog files.
Communicate with multiple HSC TapePlexes representing physically different hardware configurations.
Reduce tape processing outages by providing a second HSC instance for failover.

Security Administration Considerations for Communication

All users who want the SMC to communicate with a remote HSC subsystem must define an OMVS segment in RACF for the userid associated with the SMC. If this is not done, a z/OS UNIX process initialization failure occurs. To define the OMVS segment, refer to the IBM publication z/OS IBM Communications Server IP Migration Guide. If you use a functionally equivalent security product (for example, ACF2), refer to the documentation for that product.

Optionally, you can secure (encrypt) complete communications using Application Transparent Transport Layer Security (AT-TLS), an application distributed as part of the IBM z/OS operating system.

AT-TLS provides data encryption and decryption based on policy statements specified in the Policy Agent. For more information about implementing AT-TLS, refer to Application Transparent Transport Layer Security (AT-TLS) information in the z/OS Communications Server: IP Configuration Guide and Policy Agent information in the z/OS Communications Server: IP Configuration Reference.

Defining Server Paths

For any HSC TapePlex that resides on a different host than the SMC, you must issue the SMC SERVer command. This command defines a named path to the HSC library control system, or server, on a different MVS host.

The first server you define is considered to be the primary server. Additional servers are secondary servers. If a communication error occurs on the primary server during allocation or mount processing, SMC automatically switches communication to the first available secondary server. If a communication error occurs on this secondary server, the SMC automatically switches to the next available secondary server.

Refer to the ELS Command, Control Statement and Utility Reference for more information about the SMC SERVer command.

SMC Monitor Functions

SMC provides several monitor functions which ensure that the SMC subsystem and all client/server communications are operating correctly. See Chapter 7, "Monitor Functions and Recovery Procedures".

Using the SMC HTTP Server Component

The SMC HTTP server component provides the ability for communication between the SMC (client) and an HSC on another host (server). It executes under the SMC address space on the host where HSC executes as a server. It is not required on a host where only the SMC executes.

Starting and Stopping the SMC HTTP Server

The SMC HTTP server component is not automatically started during SMC initialization.

To start the SMC HTTP server, you must include the SMC HTTP STArt command in either the SMCPARMS or SMCCMDS data set.

Once the SMC HTTP server is active, you can issue the HTTP command from the console to stop or restart the HTTP server at any time.

Note:

Refer to the ELS Command, Control Statement and Utility Reference for more information about the SMC HTTP command.

Displaying SMC HTTP Server Status

Issue the SMC HTTP command with the LIst parameter to display SMC HTTP server status information and interval statistics.

Include the DETail parameter to display additional information including I/O, error, accept and reject counts, and CGI use count.

Note:

Refer to the publication ELS Messages and Codes for a listing of SMC HTTP server messages.

Region Size Considerations with SMC HTTP Server UUI Requests

When an SMC client directs UUI requests to the SMC HTTP server, some or all of these requests will execute in the SMC address space where the HTTP server is executing. If you attempt to execute several requests simultaneously, SMC storage shortage abends may occur.

UUI functions that may consume a large amount of virtual storage include VTCS EXPORT and reports that use the SORT feature, including VOLRPT, VTVRPT, and MVCRPT.

It is recommended that you allocate the maximum region size (0M) to the SMC running the HTTP server.

XAPI Client Interface to ACSLS Server

The XML API (XAPI) is Oracle's StorageTek API that enables StorageTek clients and servers to communicate using a common protocol over TCP/IP.

With the introduction of this XAPI, clients who were previously required to use an MVS based server (Oracle's StorageTek Host software Component) for real tape processing can now use ACSLS 8.4 or later (with XAPI support enabled) as follows:

An SMC client on MVS can now request real tape requests from an ACSLS server with XAPI support enabled (without requiring MVS/CSC).
A VM Client can now request real tape services from an ACSLS server with XAPI support enabled.

If you use an SMC or VM Client to connect to an ACSLS server with XAPI support enabled, you must use SMC or VM Client TAPEPlex and SERVer commands to define the ACSLS application as a TapePlex and define the TCP/IP control path between the client and server. Refer to the ELS Commands, Control Statement, and Utility Reference for information about these commands.

The majority of client-server interaction between SMC and VM Clients, and an ACSLS server with XAPI are transparent to the end user. Requests for volume information, mounts, and dismounts are generated automatically by the SMC and VM Client and are processed without operator intervention.In addition to these automatic interactions, the ACSLS server with XAPI provides additional administrator, configuration, and operator commands that enable you to manage the XAPI component. Refer to the ELS publication XAPI Client Interface to ACSLS Server Reference for information about these commands.

SMC Configuration Scenarios

This section describes the following common SMC configuration scenarios:

"Scenario 1: Single TapePlex with SMC and HSC on the Same Host"
"Scenario 2: Single TapePlex using the SMC Client/Server Feature"
"Scenario 3: Two TapePlexes Accessed by a Single SMC"

These scenarios are not intended to be an exhaustive list of client/server scenarios. The SMC does not limit the number of TapePlex(es), or communications paths that can be defined.

In addition these scenarios do include SMC to MVS/CSC communication, which is required when the server is ACSLS.

Note:

MVS/CSC 7.1 and later is not compatible with LibraryStation. In an MVS-only environment, you must use the SMC client/server feature to provide communication between MVS hosts. See "Using the SMC Client/Server Feature" for more information.

In a configuration with multiple StorageTek TapePlexes (as illustrated in Scenario 3), SMC directs allocation of each DD statement to the appropriate TapePlex based on TAPEREQ statements and POLicy commands, specific volume locations, and available scratch volumes.

Scenario 1: Single TapePlex with SMC and HSC on the Same Host

In this scenario, SMC and HSC execute on the same MVS host connected to a single TapePlex (represented by a single CDS).

The following figure illustrates this scenario:

Figure 3-1 Single TapePlex with SMC and HSC on the Same Host

This configuration utilizes three address spaces:

Initiator Address Space, from which allocation and mount events originate
SMC Address Space, which intercepts those events
HSC Address Space, to which SMC sends requests for drive and volume data, and mount requests

The following TAPEPlex command defines the local HSC TapePlex:

TAPEPLEX NAME(PLEX1) LOCSUBSYS(HSC0)

PLEX1 is the name of the local TapePlex, and HSC0 is the local MVS subsystem name for the HSC.

Scenario 2: Single TapePlex using the SMC Client/Server Feature

In this scenario, SMC executes on a client host without HSC, with multiple paths to a remote TapePlex (represented by a single CDS) and HSC running on multiple hosts.

The following figure illustrates this scenario:

Figure 3-2 Single TapePlex using the SMC Client/Server Feature

The following TAPEPlex and SERVer commands are required for the SMC on MVSA:

TAPEPLEX NAME(PLEX1)
SERVER NAME(MVSBPATH) TAPEPLEX(PLEX1) HOST(MVSB)
SERVER NAME(MVSCPATH) TAPEPLEX(PLEX1) HOST(MVSC)

Requests originating in an Initiator Address Space on MVSA are intercepted by the SMC Address Space on MVSA. The SMC on MVSA sends requests for volume and drive data, and mount requests to the server on MVSB or MVSC.

On MVSB and MVSC, the SMC may operate only with the local HSC, or may use the communications facility to provide a backup, as shown:

The following TAPEPlex and SERVer commands are required for the SMC on MVSB:

TAPEPLEX NAME(PLEX1) LOCSUBSYS(HSC1)
SERVER NAME(MVSCPATH) TAPEPLEX(PLEX1) HOST(MVSC)

The HTTP component is defined for the SMC on MVSB:

HTTP START

The following TAPEPlex and SERVer commands are required for the SMC on MVSC:

TAPEPLEX NAME(PLEX1) LOCSUBSYS(HSC2)
SERVER NAME(MVSBPATH) TAPEPLEX(PLEX1) HOST(MVSB)

The HTTP component is defined for the SMC on MVSC:

HTTP START

The above TAPEPlex and SERVer commands allow MVSB to act as the backup library server to MVSC, and MVSC to act as the backup library server to MVSB.

Note:

See "SMC Drive Type Information Synchronization" for information about how the SMC acquires drive type information from the HSC and MVS/CSC.

Scenario 3: Two TapePlexes Accessed by a Single SMC

In this scenario, a single SMC communicates with two TapePlexes (represented by two CDSs).

The following figure illustrates this scenario:

Figure 3-3 Two TapePlexes Accessed by a Single SMC

In this scenario, assume there are two TapePlexes (represented by two CDSs).

SMC communicates directly with HSC on the same host.
SMC uses the HTTP server to communicate with HSC on different hosts (MVSB and MVSC).

Allocation and mount requests originating in an Initiator Address Space on MVSA are intercepted by the SMC on MVSA. These requests are then sent to either the local HSCL executing on the same host, to HSC1 executing on host MVSB, or to HSC2 executing on host MVSB.

The following TAPEPlex and SERVer commands are required for the SMC on MVSA:

TAPEPLEX NAME(PLEX1) LOCSUBSYS(HSC0)
TAPEPLEX NAME (PLEX2)
SERVER NAME(MVSBPATH) TAPEPLEX(PLEX2) HOST(MVSB)
SERVER NAME(MVSCPATH) TAPEPLEX(PLEX2) HOST(MVSC)

Note:

See "SMC TapePlex Selection" for information on how the SMC selects among multiple TapePlexes to determine an ”owner” for each allocation request. That is, each DD in a job step may have a different TapePlex owner).

The following TAPEPlex and SERVer commands are required for the SMC on MVSB:

TAPEPLEX NAME(PLEX2) LOCSUBSYS(HSC1)
SERVER NAME(MVSCPATH) TAPEPLEX(PLEX2) HOST(MVSC)

The HTTP component is defined for the SMC on MVSB:

HTTP START

The following TAPEPlex and SERVer commands are required for the SMC on MVSC:

TAPEPLEX NAME(PLEX2) LOCSUBSYS(HSC2)
SERVER NAME(MVSBPATH) TAPEPLEX(PLEX2) HOST(MVSB)

The HTTP component is defined for the SMC on MVSC:

HTTP START

Note:

There are no predefined limits to the number of TapePlexes or server paths that a single SMC can have configured.

Client/Server Drive Address Mapping

SMC and HSC provide facilities that allow you to manage an environment in which drive addresses are different between client and server hosts. Use the following scenarios to help you determine whether client/server drive address mapping is required, and what actions and facilities are required.

Scenario 1

Client/server processing is not used.
Each MVS host runs a copy of HSC.

Action Required: None

Scenario 2

Client/server processing is used.
Device addresses are identically defined for all hosts participating in a single client/server network.

Action Required: None

Scenario 3

Client/server processing is used.
Device addresses are identically defined for all hosts in a single client/server network, but not all devices are defined to all hosts.

Action Required: Drive address mapping is not required. However, you must use the HSC SET SLIDRIVS utility to define all drive addresses on hosts that will be used as servers, even if the devices are not defined to the host. Refer to the ELS Command, Control Statement, and Utility Reference for more information about the SET SLIDRIVS utility.

Scenario 4

Client/server processing is used.
Device addresses are identically defined to all HSC hosts, but one or more SMC client-only hosts use a different set of addresses for the same device.

Action Required: Use the SMC DRIVemap operator command to map the SMC client host addresses to the HSC host addresses. SMC performs the necessary address translations in influencing allocations and requesting mounts from the server. Refer to the ELS Command, Control Statement, and Utility Reference for more information about the DRIVemap command.

Scenario 5

Client/server processing is used.
Two MVS hosts (MVS1 and MVS2), both running HSC and SMC.
One MVS host (MVS3) running only SMC but defined as communicating to either of the two hosts as a server.
Device addresses are defined differently among all three hosts. For example:For example:
- MVS1 (AA0-AAF)
- MVS2 (BA0-BAF)
- MVS3 (CA0-CAF)

Action Required:

Since the SMC on MVS3 can communicate with either the MVS1 or MVS2 host for a particular mount event, you must use the HSC SET utility, SET DRVHOST, to designate one of these hosts as the ”drive host master.” For example, MVS1 (AA0-AAF).

Once the drive host master is specified in the HSC CDS, the addresses associated with that host master (AA0-AAF) are used by both MVS1 and MVS2 when communicating with the SMC.

If desired, you can add a dummy host ID to be the HSC DRVHOST, and use nonexistent drive addresses to map to client addresses. For example, use the HSC SET NEWHOST utility to define host name DRVDUMMY and define the device range as 000-00F.

Refer to the ELS Command, Control Statement, and Utility Reference for more information about the HSC SET DRVHOST utility and HSC SET NEWHOST utility.
Use the SMC DRIVemap operator command on clients MVS2 and MVS3 to map drive addresses BA0-BAF and CA0-CAF to the server addresses AA0-AAF. Refer to the ELS Command, Control Statement, and Utility Reference for more information about the DRIVemap command.

SMC Drive Type Information Synchronization

The SMC acquires drive type information from the ELS library control systems, HSC and MVS/CSC using configuration queries sent from the SMC to each defined TapePlex.

For HSC subsystems, drive configuration changes are automatically recognized by the SMC for both local and remote systems.
For MVS/CSC subsystems, an SMC RESYNChronize command must be issued whenever the equivalent MVS/CSC command is issued. Refer to the ELS Command, Control Statement, and Utility Reference for more information about the RESYNChronize command.

Specifying Drive Type Information Using SMC UNITAttr Commands

The SMC UNITAttr command enables you to augment or override information returned from ELS library control system configuration queries as required by the local host tape device configuration. Specifically, the UNITAttr command enables you to do the following:

Set MODEL=IGNORE for device addresses not available for this host.
Specify model types for nonlibrary devices on this host.
Specify NOTAPEPLEX for a nonlibrary device address or range on this host, that are TapePlex owned devices on other hosts.
Specify TapePlex ownership for a device address or range that is defined to multiple TapePlexes, but for this host the attached devices belong to the specified TapePlex.
Specify TapePlex ownership and model for devices that may be referenced by a mount after the SMC is started, but before the TapePlex is initialized.

Note:

UNITAttr commands are not required, and should only be issued under the conditions described in this section.

Specifying SMC UNITAttr Commands for Inaccessible Devices

To define devices that are represented by a UCB, but are not accessible from this host, issue an SMC UNITAttr command for each inaccessible device as follows:

UNITATTR ADDR(ccuu) MODEL(IGNORE)

UNITAttr MOdel(IGNORE) processing remains unchanged from previous releases. As a result, SMC does not include the device in any of its processing.

Specifying SMC UNITAttr Commands for Nonlibrary Devices

To define nonlibrary device types on this host, issue an SMC UNITAttr command for each nonlibrary device as follows:

UNITATTR ADDR(ccuu) MODEL(model)

A nonlibrary device is a StorageTek device that requires additional model information to be defined to differentiate it from other nonlibrary devices with similar UCB characteristics.

Specifying SMC UNITAttr Commands for Nonlibrary Devices with the Same Address as a TapePlex-Owned Device

If a device address for your host overlaps with a device address for a TapePlex owned device, and the TapePlex owned device is inaccessible from this host, issue an SMC UNITAttr command specifying the NOTAPEPlex parameter as follows:

UNITATTR ADDR(ccuu) MODEL(model) NOTAPEPLEX

As a result, if a TapePlex such as HSC claims ownership through data returned from a configuration query, NOTAPEPlex overrides the TapePlex. The configuration information is ignored and the device remains a nonlibrary device.

If you fail to specify NOTAPEPlex, the TapePlex configuration information overrides the UNITAttr specified without the NOTAPEPlex parameter, and the device definition changes from a nonlibrary to TapePlex owned device.

Specifying SMC UNITAttr Commands for TapePlex-Owned Devices with the Same Address as Another TapePlex-Owned Device

If your configuration includes multiple TapePlexes with overlapping device addresses or ranges, and both TapePlexes are defined to the SMC, enter a UNITAttr command with the TAPEPlex parameter to establish which TapePlex owns the specified device or range on this host. Enter a UNITAttr command for each of the duplicate drive addresses as follows:

UNITATTR ADDR(ccuu) MODEL(model) TAPEPLEX(name)

Example

Assume the following:

Host MVSA includes two TapePlexes, HSC1 and HSC2.
HSC1 includes a 9840 device range 2900-2903.
HSC2 includes a 4480 device range 2900-2903.
However, on MVSA, devices 2900-2903 are attached to HSC1. MVSA has no connection to the HSC2 device range.

Given this scenario, issue an SMC UNITAttr command as follows:

UNITATTR ADDR(2900-2903) MODEL(9840) TAPEPLEX(HSC1)

This command directs the SMC to ignore any configuration information for the specified devices from any TapePlex other than the specified TapePlex.

Note:

If MVSA recognized address range 2900-2903 defined to HSC2 as a different address range (for example, 4900-4903), MVSA would use the SET DRVHOST facilities to define address range 2900-2903 on HSC2 as address range 4900-4903 for any client configuration queries. See "Client/Server Drive Address Mapping."

Specifying SMC UNITAttr Commands for Devices in TapePlexes that are Initialized After the SMC

To define TapePlex owned devices when tape jobs are executed after the SMC starts but before the TapePlex is initialized, enter an SMC UNITAttr command for all TapePlex owned devices as follows:

UNITATTR ADDR(2900-2903) MODEL(9840) TAPEPLEX(HSC1)
...
UNITATTR ADDR(9000-903F) MODEL(VIRTUAL) TAPEPLEX(HSC1)

This directs the SMC to keep track of any tape policy for pending mounts, including VTCS MGMTCLAS.

SMC TapePlex Selection

When the SMC intercepts a specific or scratch allocation request, it selects an owning TapePlex to service the request. The following criteria are evaluated by the SMC in the order shown to determine which TapePlex controls the allocation request:

TapePlexes are interrogated in the order they are defined. If TAPEPlex commands are defined to the SMC, the order of the TAPEPlex commands is used. If TAPEPlex commands are not defined to the SMC, the order in the MVS SSCVT table is used.
If the Eligible Device List (EDL) for the request does not contain drives owned by a specific TapePlex, that TapePlex cannot own the request.
If an applicable SMC POLicy requests a specific TapePlex, it is selected as the request owner.
If the SMC POLicy esoteric contains only drives in a single TapePlex, it is selected as the request owner.
If the requested specific volume serial is specified in a TAPEREQ statement, the POLicy associated with the TAPEREQ determines the owner.
If a specific requested volume is found in a TapePlex, that TapePlex is considered the owner unless overridden by explicit esoteric or TapePlex selection. If the volume is not found in a TapePlex, but that TapePlex contains a VOLPARM definition for that volume, then the TapePlex is considered the owner if the specific volume is not found in any other TapePlex.
If a TapePlex indicates that it has scratch volumes for the request, it is considered the owner unless overridden by explicit esoteric or TapePlex selection. If the TapePlex does not have scratch volumes for the request, but the specified subpool name is known to the TapePlex, then the TapePlex will be considered the owner if scratch volumes are not found in any other TapePlex.

To select a TapePlex owner from among multiple libraries, specify a TapePlex name using the TAPEPlex parameter on the SMC POLicy command. Refer to the ELS Command Control Statement, and Utility Reference for information about this command.