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.
This section discusses the acssa and acsss user IDs, which administer ACSLS in support of client applications.
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.
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, you must 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 remote 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
This section introduces the acsss command.
The acsss command is a start, stop, and status macro that manipulates the various services associated with the ACSLS application. See the following:
After initial startup and recovery, ACSLS is normally in the run state and ready to handle client activity. You can choose to put it into an idle state, which suspends client request processing. This is a good practice before shutting down ACSLS. You may also wish to hold off client requests temporarily, while updating or re-configuring a library.
To suspend client request processing by putting ACSLS in the idle state, enter the following command from cmd_proc:
idle
The user can continue to issue ACSLS operations using cmd_proc in idle state. To resume client request processing after an earlier idle command, enter the following command from cmd_proc:
start
ACSLS resumes request processing.
ACSLS must be in run state in order to process any cmd_proc commands other than query server. If you start a session when ACSLS is not running, you will receive a socket communication error.
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.By default, an automatic query server request is performed by default when cmd_proc is started. You can suppress this initial query server request by starting cmd_proc with the -q option.
You can suspend cmd_proc to perform UNIX commands, and then manually resume cmd_proc. Any in-process requests that you initiated will continue 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 desired UNIX operations.
To resume cmd_proc, enter the fg UNIX command.
To terminate cmd_proc:
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.
The default mode for cmd_proc is a windowed mode using curses. This versatile interface works well with most terminal types and requires a minimum 24-line by 80-character window. The curses interface divides the screen into 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 command in its default mode, you see general server status messages displayed at the top of the window while your user-specific interactions are displayed at the bottom.
The following example shows the cmd_proc window displayed when you log in as acssa. In curses mode, the cmd_proc window appears as a split screen. The top section is the message area and the bottom section is the command area, where you enter ACSLS commands at the prompt. Note that the output display is actually larger, displayed within a 24-line area on the screen.
$ cmd_proc
-------------------------- Oracle ACSLS x.x.x---------------------------
ACSSA> query server
2019-08-20 11:50:06 Server Status
Identifier State Free Cell Audit Mount Dismount Enter Eject
Count C/P C/P C/P C/P C/P
run 1253 0/0 0/0 0/0 0/0 0/0
One disadvantage of curses mode is its limited ability to retain a history of user interactions with the ACSLS server, since the space for those interactions is limited to the bottom half of the 24-line window.
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 that are longer than 80 characters.
To avoid the problems noted with curses mode, you can start cmd_proc in line mode. Running in line mode, cmd_proc operates within a conventional terminal window that includes a scrollable command history (limited only by the size of the buffer).
You can use cmd_proc in line mode by specifying the following option:
cmd_proc -l
One disadvantage of line mode operation is the mixture of STDOUT and STDERR messages that are output to the screen, displayed in the same spot where you may be attempting to enter a new command.
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 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 output on the line where you are typing, you may prefer to redirect that output elsewhere. See "Redirecting Output from cmd_proc".
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 |
The cmd_proc_shell utility can be used to run cmd_proc as a conventional shell operation, executing ACSLS commands that are passed as input arguments. It supports execution of a single command or multiple commands.
The utility provides shell-friendly access to cmd_proc functions, while retaining all of the benefits and attributes of the shell environment including command history, command editing, output filtering and terminal scrolling. This can be helpful in ad-hoc shell sessions, and when used in shell scripts.
To supply multiple commands as arguments, a new line (either quoted or unquoted, as in the examples) is used to separate the individual commands. Spaces around the new line characters are not necessary, but are included here for readability.
Some examples of cmd_proc_shell:
cmd_proc_shell query server cmd_proc_shell query server \\n query port all cmd_proc_shell 'query server \n query port all'
To view only offline CAPs:
cmd_proc_shell q cap all | grep -v online
Note:
The cmd_proc_shell utility does not require a logoff command -- a logoff is automatically performed.
The utility does not provide prompts or keyboard shortcuts -- curses mode and line mode do have interactive prompting and command help/retry.
You can use an input file to supply the commands that you want cmd_proc to process. For example, the following input file (named cmd_filename) 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 with an input file, enter the following command:
cmd_proc -q < cmd_filename
Alternatively, an input script can invoke cmd_proc directly, and supply commands in-line. Make sure that the script file is executable for user acsss.
ls -l cmd_scriptname -rwxrwxrwx 1 acsss acsls 49 Aug 22 13:49 cmd_scriptname cat cmd_scriptname cmd_proc -lq << -EOF query drive 0,0,0,0 query volume JB1400 mount JB1400 0,0,0,0 dismount JPB1400 0,0,0,0 force logoff -EOF $ ./cmd_scriptname
You may wish to redirect system messages to some other destination than the screen, to focus solely on the commands and command output. (In curses mode these appear in the upper half, including the copyright.) To direct those messages elsewhere, you can run cmd_proc (in various modes) as follows:
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. You can open a second shell window and view a running tail of that file.
You can also perform intended cmd_proc operations without viewing system status information at all, by redirecting STDERR to /dev/null:
cmd_proc -l 2> /dev/null
You can start cmd_proc using an input file, as above, and also redirect the STDOUT results to another file. To run a set of commands and capture the results for verification:
cmd_proc -q < cmd_filename > result-filename
By default, cmd_proc display area messages are written to STDERR. However, you can redirect these messages as well:
cmd_proc -q < cmd_filename > result-filename 2>> result-filename
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 |