This chapter provides an overview of ACSLS.
Automated Cartridge System Library Software (ACSLS) is Oracle's StorageTek server software that controls a StorageTek tape library. An Automated Cartridge System (ACS) is a group of tape libraries connected through pass-thru-ports (PTPs). ACSLS accesses and manages information stored in one or more ACSs through command processing across a network. The software includes a system administration component and interfaces to client system applications, and library management facilities.
ACSLS HA is a hardware and software configuration that provides dual-redundancy, automatic recovery and automatic fail-over recovery to ensure uninterrupted tape library control service if a component or subsystem fails.
Refer to the ACSLS-HA Installation, Configuration, and Operation guide for more information on running ACSLS 8.4 on Solaris 11 with ZFS file systems. This version supports ACSLS software installation in any user-defined file system.
This section discusses the acssa and acsss user IDs.
The acssa login provides access to cmd_proc, the console user interface for library control operations, and a limited set of ACSLS utilities.
A typical shell environment for acssa includes one or more windows running cmd_proc and a window that monitors the running tail of the ACSLS event log.The acssa login environment provides access to both of these resources:
$ cmd_proc $ acs_tail $LOG_PATH/acsss_event.log
The acsss login provides access to these and all other administrative utilities for general maintenance, configuration, database backup and restore, shell utilities, and general diagnostics.
The acsss command is a start, stop, and status macro that manipulates the multiple services associated with the ACSLS application.See the sections "Starting and Monitoring ACSLS" and "The acsss Macro".
This section discusses cmd_proc.
The following example shows the cmd_proc window displayed when you log in as acssa. In curses mode, the cmd_proc window is a split screen where the top section is the message area and the bottom section is the command area. You enter ACSLS commands at the prompt.
ACSLS must be running to accept commands. You can suppress this initial query server request when you start cmd_proc with the "-q" option:
cmd_proc -q
--------------------------ACSLS x.x.x---------------------------
ACSSA>query server
2008-01-23 15:41:42
Server Status
Identifier State Free Cell Audit Mount Dismount Enter Eject
Count C/P C/P C/P C/P C/P
run 234 0/0 0/0 0/0 0/0 0/0
The ACSLS cmd_proc is an easy-to use interface that keeps you informed of general server status information while it handles your own requests. The default mode for cmd_proc is curses. This is a versatile interface that works well with most terminal types and it uses a standard 24-line by 80-character window. The curses interface splits the screen in two sections, where messages bound for STDERR are sent to the window upper half and messages bound for STDOUT are sent to the bottom half.
When you use the ACSLS cmd_proc in its default curses mode, you see general server status messages displayed at the top of the window while your user-specific interactions are displayed at the bottom.
One disadvantage of curses is its limited ability to retain a history of user interactions with the ACSLS server. The space for those interactions is limited to the bottom half of the 24-line window.
This disadvantage can be overcome if you use cmd_proc in line mode:
cmd_proc -l
In line mode, the user has all the advantages of a scrolling window where the history of interactions roll upwards into a scrollable terminal buffer, limited only to the size of the buffer.
The major disadvantage of line mode operation is its inability to split both STDOUT and STDERR into separate spaces. The output text of both sources is sent to the same spot on the screen, the single cursor line in the terminal where you are attempting to compose a request.
If your cmd_proc session is the only session on the system, this may not be a problem. But in a busy production environment where active operations are in progress with ACSLS, it may be difficult, if not frustrating, to work in a window where status information is being printed on the same line where you are composing an ACSLS request.
While it is safe to ignore the system status chatter on the line where you are typing, you may prefer to redirect that chatter elsewhere. To redirect system messages to another destination, you can run line-mode cmd_proc in the following manner:
cmd_proc -l 2> /tmp/SysChatter.out The expression 2> instructs the shell to redirect STDERR to another location. In this example, the status messages are sent to a file in the /tmp directory.
To view the system status information as you work, you can open a second shell window and view a running tail of the file where you sent the status messages:
tail -f /tmp/SysChatter.out
To perform intended cmd_proc operations, then you can redirect STDERR to /dev/null.
cmd_proc -l 2> /dev/null
The cmd_proc command in curses mode cannot display lines longer than 80 characters, and the cmd_proc window will hang if it attempts to display a line longer than 80 characters.
If this happens, the cmd_proc window can be released with Control+c and Control+d.
The output from all query and other commands is less than 80 characters per line, and the default fields reported for all records by the display command require less than 80 characters. However, displaying many optional fields may result in lines longer than 80 characters.
It is a good idea to start cmd_proc in line mode (with the –l option) when displaying many optional fields. Example: display drive * -f volume type state serial_num wwn using a cmd_proc started as cmd_proc –l.
You can suspend cmd_proc to perform UNIX commands, and resume cmd_proc. You must start cmd_proc manually. Any in-process requests that you initiated at cmd_proc continues to completion while cmd_proc is suspended.
To suspend and resume cmd_proc:
While running cmd_proc, press Control+z
The UNIX shell prompt appears.
Perform whatever UNIX operations you want.
To resume cmd_proc, enter the fg UNIX command.
While running cmd_proc, wait until all in-process activity is complete and the ACSSA> prompt has returned.
To exit cmd_proc, enter the logoff command:
logoff
The cmd_proc session terminates.
You can start cmd_proc from any terminal type that has been defined in /etc/termcap. When running in curses mode, the terminal must have a display size of 24x80 or larger.
The cmd_proc session runs in a mode that is independent of ACSLS. Start a cmd_proc session without starting ACSLS, there will be no response to your commands. You may see a socket communication error in cmd_proc attempting to run commands while ACSLS is not running.
Remote access to the ACSLS server is available from any system with an SSH client.An ssh client is a standard feature with any shell on most POSIX compliant Operating systems, including Solaris, Linux, and MacOS. For Windows environments, it is necessary to install SSH client software such as putty, WinSCP or a similar commercial application.
To access the ACSLS server remotely as user acssa, enter the following command:
$ ssh acssa@hostname
Where hostname is the host ID of the ACSLS server.
A typical remove environment for acssa includes one or more SSH login shells running cmd_proc and another shell to monitor the running tail of the ACSLS event log.
$ acs_tail $LOG_PATH/acsss_event.log
The following table describes cmd_proc keyboard shortcuts, which are <CTRL>+ keystroke combinations.
Table 1-1 cmd_proc Keyboard Shortcuts
| Key Combination | Action | Notes |
|---|---|---|
|
|
Cancels the last |
|
|
|
Returns to the |
|
|
|
Deletes the previous character on the command line. |
On most keyboards, you can also use the Enter or backspace key. |
|
|
Refreshes the |
This function is useful if the current |
|
|
Refreshes the current command line. |
This function is useful if the current command line display has been corrupted by noise on the communications lines. |
|
|
Deletes the current command line. |
N/A |
|
|
Suspends |
Enter the |
You can use an input file to automatically enter commands when you start cmd_proc. For example, the following input file verifies ACSLS by mounting and dismounting a cartridge.
query drive 0,0,0,0 query volume JB1400 mount JB1400 0,0,0,0 dismount JPB1400 0,0,0,0 force logoff
To start cmd_proc, enter the following command:
cmd_proc -q < filename
You can also start cmd_proc, specify an input file, and redirect the output to another file. Using input and output files lets you run a set of commands at cmd_proc startup and look at the results. For example, the following file shows the results of the commands run in the previous example that showed cmd_proc with only an input file.
ACSSA> query drive 0,0,0,0 1998-06-30 18:23:08 Identifier State Status Cartridge Type 0,0,0,0 online available 9840 ACSSA> query volume JPL1400 1998-06-30 18:23:09 Identifier Status Current location JB1400 home 0,0,3,0,0 ACSSA> mount JPL1400 0,0,0,0 ACSSA> Mount: JB1400 mounted on 0,0,0,0 ACSSA> dismount JPL1400 0,0,0,0 force ACSSA> Dismount: Forced dismount of JB1400 from 0,0,0,0 ACSSA> logoff ACSSA
To start an additional cmd_proc, specify an input file, and redirect the output:
While logged in as acssa or acsss, open a UNIX terminal window.
To start the cmd_proc, enter the following command:
cmd_proc -q < file1 > file2
Where file1 is the input file and file2 is the file to which the output is directed.
By default, cmd_proc display area messages write to stderr. but you can also redirect these messages. For example:
cmd_proc -q < file1 > file2 2>> file2
Use this procedure to suspend request processing by putting ACSLS in the idle state. Typically, this procedure is used before shutting down ACSLS, but you can also use it to temporarily stop ACSLS request processing.
To move ACSLS to idle state:
From cmd_proc, enter the idle command.
ACSLS processes all current requests, rejects all new requests, and goes into the idle state.
The following table shows a listing of the directories, subdirectories, and most commonly used files and shell scripts in the ACSLS directory structure.
Three variables are used for ACSLS paths. They are:
$installDir
This is the base installation directory and is /export/home/ by default.
$ACS_HOME
Located at $installDir/ACSSS/, this is the home directory for the acsss user ID and where the ACSLS product is installed.
$ACS_HOME is /export/home/ACSSS by default.
$ACSDB_BKUP
This is the directory where the ACSLS backups are saved.
Table 1-2 ACSLS Directory Structure
| Directory | Contents |
|---|---|
|
|
The base installation directory. |
|
|
Home of ACSLS java components including the ACSLS GUI and the SMCE (logical library operation) |
|
|
The home directory of the ACSLS Web-based GUI application. |
|
|
The bundled WebLogic application server package and related installation scripts. |
|
|
The un-bundled WebLogic home directory. |
|
|
A collection of third-party license information and related republished source code. |
|
(by default /export/home/ACSSS/) |
Home directory for the |
|
(by default /export/backup/) |
Database backups |
|
|
Contains ACSLS configuration files. |
|
|
Contains customized files used in access control, mixed media, and cartridge reporting. |
|
|
Contains access control sample and customized files. |
|
|
ACSLS internal configuration files. do not modify. |
|
|
Contains diagnostic files and shell scripts. |
|
|
Contains ACSLS installed shared libraries required at run-time. |
|
|
Contains ACSLS event log and utility event log files. |
|
(by default /export/home/ACSSA/) |
|
|
(by default/export/home/acsdb/) |
Database home directory. |
|
|
This is equivalent to |