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 Fujitsu's MSP/EX operating system and StorageTek library control systems, HSC.

SMC can operate with the HSC directly on the same host or remotely with an HSC on a different host, using TCP/IP and the SMC HTTP server component.
SMC can communicate with an ACSLS server with XAPI support enabled (without requiring MVS/CSC). See "XAPI Client Interface to ACSLS Server" for more information.

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 MSP syslog files.
Communicate with multiple HSC TapePlexes representing physically different hardware configurations.
Reduce tape processing outages by providing a second HSC instance for failover.

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 MSP 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 SMC 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 Security for Client/Server Communication

SMC 7.3 introduces a new XAPI security feature for client/server communication, enabled as a default in the SMC HTTP server.

The preferred method for securing XAPI transactions for TapePlexes that host ELS client applications only (SMC and VM Client) is to use the AT/TLS facilities as described in the StorageTek Enterprise Library Software Security Guide. AT/TLS is a transport layer facility that is external and transparent to ELS.

Use the ELS 7.3 XAPI security feature to secure TapePlexes that host non-ELS clients (open systems clients) or a mixture of ELS clients (SMC and VM Client) and non-ELS clients. AT-TLS can be used in these environments in addition to the ELS 7.3 XAPI security feature. However, it will not secure XAPI transactions for non-ELS clients.

ELS 7.3 provides additional user authentication facilities as part of its XAPI protocol that is internal to and wholly contained within ELS. ELS 7.3 implements a challenge-response protocol to authenticate individual XAPI client/server transactions. This protocol requires you to use the new SMC XUDB command to define userids and passwords for clients and servers. Refer to the ELS Command, Control Statement, and Utility Reference for more information about this command. Note that operational login challenge and response is completely transparent, and requires no additional user or operator intervention. XAPI login is required for each TapePlex operation (mount, dismount, lookup, scratch, and so forth). Userids and passwords are never saved or cached by server on behalf of the client.

ELS 7.3 requires XAPI security as its default. However, ELS provides facilities that enable you to control security for each client.

You can use the SMC XCLIENT command to enable an ELS 7.3 server to "exempt" individual clients from using the XAPI security protocol. Back level ELS clients (for example a 7.2 client communicating with a 7.3 server) require an ELS 7.3 XCLIENT command definition to allow them to request services from the ELS 7.3 server without an XAPI login.
You can use the HTTP command with the XSECurity (OFF) parameter to globally disable the XAPI security protocol. When HTTP XSECurity(OFF) is specified, the ELS 7.3 XAPI protocol will operate identically to the ELS 7.2 XAPI protocol (with no user authentication).

Refer to the ELS Command, Control Statement, and Utility Reference for more information about these commands.

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 are using 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 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 MSP 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 MSP 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 MSPA:

TAPEPLEX NAME(PLEX1)
SERVER NAME(MSPBPATH) TAPEPLEX(PLEX1) HOST(MSPB)
SERVER NAME(MSPCPATH) TAPEPLEX(PLEX1) HOST(MSPC)

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

On MSPB and MSPC, 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 MSPB:

TAPEPLEX NAME(PLEX1) LOCSUBSYS(HSC1)
SERVER NAME(MSPCPATH) TAPEPLEX(PLEX1) HOST(MSPC)

The HTTP component is defined for the SMC on MSPB:

HTTP START

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

TAPEPLEX NAME(PLEX1) LOCSUBSYS(HSC2)
SERVER NAME(MSPBPATH) TAPEPLEX(PLEX1) HOST(MSPB)

The HTTP component is defined for the SMC on MSPC:

HTTP START

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

Note:

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

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 (MSPB and MSPC).

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

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

TAPEPLEX NAME(PLEX1) LOCSUBSYS(HSC0)
TAPEPLEX NAME (PLEX2)
SERVER NAME(MSPBPATH) TAPEPLEX(PLEX2) HOST(MSPB)
SERVER NAME(MSPCPATH) TAPEPLEX(PLEX2) HOST(MSPC)

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 MSPB:

TAPEPLEX NAME(PLEX2) LOCSUBSYS(HSC1)
SERVER NAME(MSPCPATH) TAPEPLEX(PLEX2) HOST(MSPC)

The HTTP component is defined for the SMC on MSPB:

HTTP START

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

TAPEPLEX NAME(PLEX2) LOCSUBSYS(HSC2)
SERVER NAME(MSPBPATH) TAPEPLEX(PLEX2) HOST(MSPB)

The HTTP component is defined for the SMC on MSPC:

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 MSP 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 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 MSP hosts (MSP1 and MSP2), both running HSC and SMC.
One MSP host (MSP3) 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:
- MSP1 (AA0-AAF)
- MSP2 (BA0-BAF)
- MSP3 (CA0-CAF)

Action Required:

Since the SMC on MSP3 can communicate with either the MSP1 or MSP2 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, MSP1 (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 MSP1 and MSP2 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 command on clients MSP2 and MSP3 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 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.

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 MSPA includes two TapePlexes, HSC1 and HSC2.
HSC1 includes a 9840 device range 2900-2903.
HSC2 includes a 4480 device range 2900-2903.
However, on MSPA, devices 2900-2903 are attached to HSC1. MSPA 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 MSPA recognized address range 2900-2903 defined to HSC2 as a different address range (for example, 4900-4903), MSPA 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 MSP 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.