ACSLS Primer (taken from Support Newsletter 36 November 1998)

Document ID : KB000056204
Last Modified Date : 14/02/2018
Show Technical Document Details

When To Use The ACSLS Personality

The ACSLS personality is used when one or more CA-Alexandria servers are connected to a StorageTek library through an ACSLS server. An ACSLS server is simply a Sun or IBM machine that controls robotic access to the library. This configuration is typically used when multiple servers will be accessing the library (referred to as the "ACS", or "Automated Cartridge System" throughout the rest of this document). If a single CA-Alexandria server is directly connected to the ACS, the ACSLS personality is not required.

Theoretical Overview

Because the ACS has such a large tape capacity, and can in fact hold more than one type of media, it is likely that multiple CA-Alexandria servers will be attached to a single ACS. It is also likely that other, non-CA-Alexandria machines will require access to some of the tapes and drives inside the ACS. The ACSLS server is relied upon to handle robot and tape requests, making sure that each process has access to only those tapes it "owns."

Each CA-Alexandria server will configure one or more "logical" libraries within the ACS. All the media in each logical library will be placed under a unique lock ID, issued by the ACSLS server when the first tapes are inserted into the library. Each logical library will contain one or more drives. Each drive should be configured for use by ONE and ONLY ONE logical library. Likewise, a drive configured into a logical library should not be used by other, non-CA-Alexandria processes, though there is nothing to prevent such use. If CA-Alexandria tries to use a drive that is in use by another process, CA-Alexandria will take that drive offline.

With the ACSLS personality, there is no correspondence between slot numbers presented to the user through the CA-Alexandria GUI, and the physical location in the ACS where the tape actually resides. All tapes are actually tracked by barcode labels---when CA-Alexandria needs to perform an operation on a tape, it passes the barcode to the ACSLS server. The ACSLS server, in turn, knows the physical location of that tape, and executes the corresponding command. So, each logical library may (and probably will) consist of tapes that are scattered throughout the ACS.

Lock IDs and Scratch Pools:

To understand how CA-Alexandria works with ACSLS, it is necessary to understand two concepts: Lock IDs and Scratch Pools.

When a Lock ID has been assigned to a tape, that tape can only be used by a process that requests it using the correct Lock ID. So a lock ID is like a "password" that a process must know to use a tape. Lock IDs are assigned by the ACSLS server upon request, so that no two processes will somehow "choose" the same Lock ID.

Scratch Pools are pools of tapes that are associated with an identifying integer---the Scratch Pool ID. Typically, Scratch Pools are used as a "holding area" for tapes. When a process needs more tapes than it has, it will request one from a scratch pool. When this happens, generally that process's Lock ID will then be associated with that tape. Scratch pools may be shared by several processes, as a pool of blank tapes for example.

Tape Handling


There are two phases to inserting tapes into a logical library. First, one or more tapes must be physically inserted (or already reside) in the ACS. Then, they must be logically inserted into the correct logical library. When an insert operation is performed by CA-Alexandria, the tape(s) inserted become associated with that library's Lock ID. But how does CA-Alexandria know which tapes in the ACS to claim when an insert operation is performed? The answer lies in the "Insert Method" that is specified when the logical library is configured

There are three valid values that can be entered in the "Insert Method" field of the Library Configuration window:

1. If a CAP address is entered into this field, such as:
then any time an insert command is issued by CA-Alexandria, all of the tapes that are present in the CAP specified will be "claimed" by the logical library that issued the insert. The Lock ID for that logical library will then be associated with those tapes, and the Scratch Pool ID will be cleared.

2. If the word "SINGLE" is put in this field, followed by a colon and a scratch pool ID, such as:
then any time an insert command is issued by CA-Alexandria, a SINGLE tape from the specified scratch pool will be claimed by the logical library that issued the insert. Again, the Lock ID will be assigned to that tape, and the Scratch PoolID will be cleared.

3. If the word "ALL" is put in this field, followed by a colon and a scratch pool ID, such as:
then any time an insert command is issued by CA-Alexandria, ALL of the tapes from the specified scratch pool will be claimed by the logical library that issued the insert. Again, the Lock ID will be assigned to those tapes, and the Scratch Pool ID will be cleared.

NOTE that blank tapes that are physically inserted into the library for use by CA-Alexandria, or tapes that are scheduled to migrate back to the library from the vault, MUST first be put into the correct scratch pool if the Insert Method used references a scratch pool. Tapes in the CAP can be put into a specific scratch pool with the "alex-util" command.


Just as with inserts, how ejects are handled depends upon how the "Eject Method" field is defined when the library is configured.

There are two ways to eject media from a logical library:

1. If a CAP address is entered into this field, such as:
then any time an eject is issued, the ejected tape will be placed into the first available slot in the specified CAP. The Lock ID will be cleared.

NOTE that when this method is used, only ONE tape at a time will be ejected: even if there are 10 tapes to eject, and there are 10 empty slots in the CAP, the tapes will eject into the CAP one at a time. For each tape, the CAP door will have to unlock, open, close, relock, and be scanned for tapes that were inserted while it was open. This is a VERY time-consuming series of operations, making this a poor choice for "eject all vaultable media" operations.

2. If the word "POOL", followed by a Scratch Pool ID, is entered into this field, such as:
then any time an eject is performed, the tape(s) involved will be logically placed into the specified scratch pool. So the Scratch Pool ID will be set, and the Lock ID will be removed. This is an efficient way to eject all vaultable media, because the "alex-util" command can then be used to eject all the tapes from that scratch pool to the CAP in a single operation.

NOTE!!! that the CA-Alexandria Lock ID is removed when the tapes are placed into the eject scratch pool. Because of this, MAKE SURE that no other processes are taking scratch tapes from the pool you have identified as the eject pool. Also, make sure that the eject scratch pool is different from the insert scratch pool, if that is the insert method used.

Recovery Pools:

There is a third field in the library configuration screen: the Recovery Pool ID. In this field, enter the scratch pool ID that will be associated with CA-Alexandria's MD tapes. Unlike tapes in the insert/eject scratch pools, the MD tapes in the recovery pool will still be associated with the library's Lock ID.

Installing ACSLS

With the ACSLS personality, CA-Alexandria uses the ACSLS server to actually interact with the ACS. The interaction between CA-Alexandria and ACSLS requires a program called "ssi" be installed on the CA-Alexandria server, and a program called "csi" on the ACSLS server.The csi program is supplied by Storage Tek (with ACSLS), and installed on the ACSLS server when the ACSLS software is installed. The ssi program was also written byStorageTek, but it is supplied by Sterling Software, and installed when CA-Alexandria is installed. You will find it in the ~alexbkup/bits/<platform> directory.

The ssi program must be up and running before you can access any logical libraries you have configured (you can start the "ssi" program either before or after you configure any libraries, it makes no difference).

To start and test the ssi program:

1. cd $ALEXHOME/bits/<platform>
2. Start the ssi with: ./start_ssi <ACSLS-Server-Name> [<socket>] where <ACSLS-Server-Name> is the hostname of the ACSLS server. By default, ssi will use socket number 50004. If you want to use another socket, specify it on the command line.
3. To verify that CA-Alexandria can now communicate with the ACSLS, run the command: alex-util acsls_util [-h <socket>] -q -p 123 This will query the contents of scratch pool 123 (which probably does not exist). If you get an error message, or a list of volumes (if 123 happens to exist), you have communication. You should configure a startup/shutdown script that starts the ssi after the system reboots---otherwise, you will not have communication between CA-Alexandria and the ACSLS server until you manually start the ssi.

Configuring Logical Libraries

You can configure as many logical libraries as you like on a single CA-Alexandria server. Some ACSs support the use of multiple media types (for example, DLT and Timberline drives may reside in the same ACS). If this is the case, and a single CA-Alexandria server wants to use both types of media, you MUST configure one logical library to use one type of media, and a second logical library to use the other type of media.
To configure a logical library in CA-Alexandria:

1. Fill out the left-hand column just as you would for any other library. Most ACSs support their own automated cleaning, based on the ECC rates reported by the drives. If this is the enabled on the library, DO NOT configure automated cleaning through CA-Alexandria (cleaning based on ECC rates is more efficient than cleaning based on hours of use).
2. In the "Media Type in Logical Library" field, enter the capacity of the tapes you will be using, OPTIONALLY followed by a number of sectors to take off of the tape length reported. The optional parameter is to eliminate problems with unexpected EOM. Each sector is 200 MBytes. So to configure the use of 50 GByte tapes, taking 1 GB (five 200-MB sectors) off the end, put "50,5" in this field.
3. Set the Insert Method as desired (see above on tape handling). Use either:
<CAP address>
SINGLE:<pool ID>
ALL:<pool ID>

4. Set the Eject Method as desired (see above on tape handling). Use either:
<CAP address>
POOL:<pool ID>

5. Set the Recovery Pool ID to the scratch pool ID that will be associated with CA-Alexandria's MD tapes (see above on tape handling).
6. Make sure that any eject, insert, and recovery pool IDs are all different. Multiple logical libraries can share the same insert pool (as long as they use the same media type), though this may not be a good idea if inserts are set up to insert ALL the tapes in a scratch pool. Eject pools should probably be different, unless all tapes are scheduled to go to the same location, regardless of the logical library they were ejected from. It is ALWAYS good to have unique Recovery Pool IDs for each logical library. The Recovery Pool ID allows us to locate the CA-Alexandria database tapes for a specific library if the CA-Alexandria database is not available.
7. In the "SSI Socket-Id, enter the ssi socket being used (or leave this field blank if you are using the default socket, number 50004).

Configuring Devices

To configure a device in CA-Alexandria:

1. Fill out the left-hand column just as you would for any other device.
2. The logical device number should be the drive identifier, which is a 4-digit, comma-separated value. This is the drive identifier that would be returned by ACSSA if you issued a "query drive all" command. It has the form:
For example, this:

identifies the drive in ACS 0, LSM 0, Panel 0, Drive 1. The Drive number is NOT the SCSI ID, but the drive number. In most ACSs, drives are numbered from 1, starting at the bottom of the ACS.
3. The physical device number is actually ignored, but for the sake of consistency you can set it to match the drive number used above.
4. Specify whether or not to skip ANSI headers. Most sites will probably NOT use ANSI headers---if they don't know, they most likely aren't. However, if they ARE using ANSI headers (basically, a method of labelling tapes), managing an CA-Alexandria tape will write over this ANSI header if this field is not set correctly.

Starting/Stopping Ssi In Startup/Shutdown Scripts

The ssi program MUST be running for CA-Alexandria to access the ACSLS library, so this should be included in the startup/shutdown scripts (just as with the CA-Alexandria daemons).

For example:

       echo "Starting StorageTek ssi daemon"
       export PATH
       if [ -f start_ssi ] && [ -f ssi ] && [ -f t_parent ]
      	 start_ssi <ACSLS-server-hostname> [<socket>]
      	 echo "The files start_ssi, ssi, and t_parent are not"
      	 echo "installed on this system===ssi not started. "

Useful ACSLS Commands

The ACSLS software can be used to perform operations such as defining scratch pools, putting tapes into scratch pools, and ejecting scratch pools to the CAP. Generally, if you log on as "acssa", you will be put immediately into the ACSLS software. If you are logged on as root, you can start this with "cmd_proc." In any event, here are some commands to run once you are there:

acssa> query server
Displays the status of the library.

acssa> query acs
Displays the status of an ACS. You can specify the ACS ID on the command line.

acssa> query lsm
Displays the status of an LSM. You can specify the LSM IDon the command line.

acssa> query cap
Lists information about a CAP or CAPs. Can be followed by a CAP ID, or "all" to list information on all CAPs.

acssa> query drive.
Lists information about a drive or drives. Can be followed by a drive ID, or "all" to list information on all drives. This is useful for determining the value to enter for the Physical and Logical Device numbers in the configuration screen.

acssa> query volume
Lists information about a volume or volumes. Can be followed by a volume ID, or "all" to list information on all volumes.

acssa> query lock
Lists tapes associated with one or more lock IDs. Can be followed by a lock ID, or "all" to list info on all lock IDs.

acssa> query scratch
Displays the volumes in the specified scratch pool(s).

acssa> set lock
Sets the working lock ID. All operations performed will now use this lock ID.

acssa> unlock
Removes the lock ID from a tape.

acssa> set scratch
Assigns a scratch pool ID to one or more volumes.

acssa> define
Defines or modifies a scratch pool. Specify a low water mark of 0, and a high water mark of 88888888. Or you can do it on a single command line with: define pool <pool-id> 0 88888888

acssa> set scratch
Associates one or more volumes with a scratch pool.

acssa> delete
Deletes an empty scratch pool.

acssa> mount
Mounts a volume to a drive.

acssa> dismount
Unmounts a volume from a drive.

acssa> lock
Locks (dedicates) a volume or drive to a user.

acssa> enter <capID>
Sets the specified CAP ID to enter mode. This unlocks the CAP door---open it, fill it with tapes, and close it. The tapes will be moved from the door into slots, and then opened again. Repeat until you are done, and then press <CTRL-C> to end the enter operation.

acssa> eject <capID>
Ejects one or move volumes from the ACS.

acssa> volrpt
Generates a volume report