TMF always communicates to the tape loader via an intermediate software system that is provided by the library vendor.

For the StorageTek library, a software package called ACSLS runs on a SUN host. For the IBM library, a software package called Controlled Path Service (CPS) runs on an IBM RISC System/6000 platform. For the EMASS library, the package is called VolServ and runs on a SUN host.

These software systems, ACSLS, CPS, and VolServ, receive requests from TMF and pass them on to the actual tape libraries for processing. They also send responses back to TMF for any given action.

The diagram in Figure 3-1, shows the software and hardware configuration between the IRIX host and the StorageTek, IBM, and EMASS libraries.

Figure 3-1. Library Communication

TMF supports a variety of StorageTek tape devices and libraries. For a definitive list, see the IRIX TMF Release and Installation Guide.

TMF communicates with the ACSLS software via a child process called stknet, which TMF starts after the library is configured up (up means that it is running and waiting for tape requests).

---

Note: Check with your StorageTek representative to validate the values of CSI_UDP_RPCSERVICE and CSI_TCP_RPCSERVICE.

---

TMF supports one IBM library, IBM 3494, and specific IBM tape devices. For a definitive list, see the IRIX TMF Release and Installation Guide.

TMF communicates with the IBM CPS software via a child process called ibmnet, which TMF starts after the library is configured up.

TMF supports EMASS libraries. For a definitive list, see the IRIX TMF Release and Installation Guide.

TMF communicates with the vendor-supplied software interface, VolServ, via a child process called esinet which TMF starts after the library is configured up.

The UNIX storage server host name must be defined in the TMF configuration file, the local /etc/hosts file. For more information, see the hosts(4) man page. The UNIX storage system host name also must be specified in the server parameter of the LOADER definition in the /etc/config/tmf.config file.

If you are using the UNIX version of the StorageTek library, you must also ensure that CSI_UDP_RPCSERVICE and CSI_TCP_RPCSERVICE are set to TRUE in the /usr/ACSSS/rc.acsss file of the UNIX storage server host. Your local StorageTek representative should be able to assist you in this matter.

It is recommended that you use the installation documentation for the libraries at your site to correctly install these products.

A mixed environment consists of devices serviced by a manual operator (attended mode) and devices serviced by a library (unattended mode). If TMF services mount requests in a mixed environment, you must organize the devices to use both devices and loaders in the most efficient manner possible.

A volume has a domain associated with it and, as such, has a preferred or best loader to service a mount request. If the domain of a tape cartridge is a tape vault, the best loader is an operator. If the tape cartridge resides in the library's domain (silo), the best loader is the library.

Each tape device belongs to a device group, which is a collection of devices with equivalent physical characteristics. Although cartridge devices can have equivalent physical characteristics, you should consider the manner in which the devices will be serviced to determine whether or not they should be grouped.

One of the principal reasons for using a library is that the loader can be run in unattended mode (that is, without an operator). Using the library in this manner means that no imports or exports are considered, and a user-requested tape mount that cannot be satisfied by the library is canceled.

The easiest way to prevent canceled mounts is to assign the library drives to a device group different from the one serviced by manual operators. A user can then determine whether the required device group is available before requesting a tape mount. The only drawback to this method is that the user must be aware of the domain in which the tape resides and, if necessary, make changes to scripts if the domain of the tape changes.

For operations that have 24-hour operator coverage, all tape cartridges can be assigned to one device group, with the operator deciding whether the mount request should be queued or canceled, or whether the volume should be imported or exported. In this case, the user need not be concerned about the domain of the tape.

Another administration issue is the accessibility of tape cartridges in a library. In the past, control of a volume serial number (VSN) was provided by an operator or by security programs on a front-end computer. With a library, control of VSNs does not exist; therefore, with the distributed TMF software, any user may request the mounting of any VSN in the domain of the library.

A site may provide access control to VSNs through two user exits. For information on user exits, see the IRIX TMF Release and Installation Guide.

Procedure 3-1, and Procedure 3-2, list the steps you need to take before you use TMF with OpenVault.

Procedure 3-2. TMF Checklist

Modify the tmf.config file to support OpenVault in the LOADER statement. For information on the tmf.config file, see the tmf.config(5) man page.

1. Define a OpenVault loader:

   type = OPENVAULT

   
   

2. Specify where the OpenVault server is running by entering the name of the host:

   server = host_name

   
   

3. Either use the TMF default (tmf) for the OpenVault application name or specify a different name for TMF with the following parameter:

   ov_tmf_application_name = tmf_application_name

   
   

4. Specify the pathname of the key file for TMF if the OpenVault security key is used:

   ov_tmf_keyfile = keyfile_path_name

   
   

   For more information on the key file and security key, see the OpenVault Operator's and Administrator's Guide.

---

Note: When TMF requests OpenVault to mount or unmount a cartridge (physical tape), TMF uses the physical cartridge label (PCL) as the external volume identifier for the -v option in the tmmnt(1) command. For more information on tmmnt(1) usage, see the tmmnt(1) man page and the IRIX TMF User's Guide.

---

You can also use a Perl script to issue OpenVault commands shown in Example 3-5.

---

Caution: If you decide to use scripts, you should be sure they are doing what you intend.

---

#! /usr/bin/perl -w         require 5.002;
use Socket;
use FileHandle;

$ov_server = `hostname`;
chop $ov_server;
$ov_port = "44444";

# Setup connection to OpenVault server process.
# See "Programming Perl" 2nd ED., page 498, for discussion
# on network programming with Perl.
$iaddr = inet_aton($ov_server) or die "no host: $ov_server";
$paddr = sockaddr_in($ov_port, $iaddr);
$proto = getprotobyname("tcp");
socket(SOCK, PF_INET, SOCK_STREAM, $proto) or die "socket: $!";
connect(SOCK, $paddr) or die "connect: $!";

SOCK -> autoflush();

# Once a connection is made to the OpenVault server
# process, it is treated just like any other file.
# Send initial data to server.
print SOCK "$ov_server\r\ntmf\r\nOnlyInstance\r\nCAPI\r\n0\r\n";

# Get response and ignore it.
# Response should only be 'ok'.
$line = <SOCK>;

# Send 'hello' greeting.
print SOCK "hello client['tmf']instance['onlyInstance']";
print SOCK "language['CAPI']versions['1.0'];\r\n";

$line = <SOCK>;
if (substr($line,0,7) eq "welcome") {
   # 'welcome' is the correct result.
}
elsif ( substr($line,0,9) eq "unwelcome") {
   # The server has rejected us.
   die "Server Not Allowing Request\n";
}
else {
   # Got an undefined answer from server.
   # We should not get here.
   die "Undefined Error\n";
}

# Send 'show' command.
$ov_cmd = "show match[strEQ('123456' CARTRIDGE.'CartridgePCL')]
           report[DRIVE.'DriveName']
           reportmode[value]";
$task_id = " task['66666'];\r\n";
print SOCK $ov_cmd . $task_id;
print $ov_cmd . $task_id;

# Get command 'accepted' from server.
$line = ;
print $line;

# Get command 'success' from server
# along with results.
$line = <SOCK>;
print $line;
# A non-trivial script would parse out the results
# and display it in a more human readable form.

print "Saying Goodbye to OV\n";
print SOCK "goodbye task['1'];\r\n";

# Get command 'accepted' from server.
$line = ;

# Get command 'success' from server.
$line = <SOCK>;

close(SOCK) or die "close: $!";
exit;  

You must have superuser privileges to start or stop the message daemon.

Start the message daemon prior to starting TMF by entering the following command:

/usr/tmf/bin/msgdaemon

To stop the message daemon, enter the following command:

/usr/tmf/bin/msgdstop

Only one message daemon can be running at any time. If you attempt to start the message daemon while it is already running, you will receive an error message.

All messages are logged by the message daemon as they are received. The logs are kept in the msglog.log log file in the /var/spool/msg directory. The /etc/newmsglog shell script, which resides in the /usr/tmf/bin directory, saves the last several versions of the log. The versions are called msglog.log.0, msglog.log.1, and so on, with msglog.log.0 being the most recent. This script also instructs the message daemon to reopen the log file; it should be run from the crontab(1) command.

The message daemon request pipe is located in the /var/spool/msg directory.

Table 3-1 shows the message daemon commands and the permissions required to access them.

The operator display provided by the oper(8) command can be run from any terminal defined in the /usr/lib/terminfo file. It requires at least 80 columns and 24 lines. The three lines at the bottom of the operator display screen are used for input and for running commands that do not display information on the screen. The rest of the screen is used as a refresh display to display messages and to run other display commands.

The $HOME/.operrc configuration file lists the commands to be run as refresh displays and those that require full control of the screen. $HOME is the user's home directory. If this file does not exist, the default configuration file, /usr/tmf/version/oper.rc, is used.

Commands not listed in the configuration file are assumed to be nondisplay commands, which are also called action commands.

Table 3-2 describes two of the action commands available from the operator display:

Action messages that require replies from the operator are primarily tape mount messages, but they may be other types of messages to which users need responses. These messages are logged by the message daemon. An action message is deleted when the operator replies to it or the sender cancels it.

Installing TMF does not enable starting TMF automatically at system startup. To enable automatic startup of TMF and the message daemon, execute the following chkconfig(1m) command as root:

chkconfig -f tmf on

To stop TMF from starting automatically at system startup, execute the following as root:

chkconfig -f tmf off

If you chose not to use the chkconfig(1m) command, you can start and stop TMF with the tmdaemon(8) and tmstop(8) commands. You can also use these commands to stop and start TMF once it has been started automatically when the system is booted.

To start TMF explicitly, enter the following tmdaemon(8) command:

/usr/tmf/bin/tmdaemon

Options exist for the tmdaemon(8) command. For descriptions of these, see the tmdaemon(8) man page.

TMF is stopped by the following tmstop(8) command:

/usr/tmf/bin/tmstop

The tmstop(8) command has no options.

Table 3-3 shows these commands and the permissions required to access them.