Managing your libraries may consist of the following tasks:
"Registering the IP Addresses of Primary and Secondary LANs"
"Queue and Retry Mounts and Dismounts when Library is Temporarily Unavailable"
"Reconfiguring ACSLS When Tape Drives are Moved, Added, or Removed"
ACSLS lets you configure or reconfigure libraries without assigning all ACS numbers in sequence.
Example:
You want to migrate from an SL8500 library to an SL3000 library. The SL8500 ACS is now ACS 0 and the SL3000 ACS is ACS 1.
Skipping ACS numbers lets you migrate all of the cartridges and drives to the SL3000 ACS and remove the SL8500 ACS without having to renumber the SL8500 ACS.
If you renumbered the SL3000 ACS all volumes would be deleted, and then re-added in a subsequent audit. It would also cause all of the drive_ids to change.
To change the number of an existing ACS, refer to "acs_renumber.sh".
You must reconfigure ACSLS to update the drive serial numbers and drive types in the ACSLS database whenever tape drives are swapped between locations or a tape drive in the library is replaced with a different tape drive. Reconfigure to add or remove tape drives when they are inserted into or removed from a library. Adding tape drives to the Media Validation pool removes them from access by ACSLS, and removing tape drives from the Media Validation pool adds them to ACSLS.
If a tape drive is replacing an existing drive, the drive type and serial number is not updated until ACSLS reads the tape drive status from the library. This happens at:
ACSLS startup
When the ACS or LSM goes not ready and then ready, causing ACSLS to recover the library
When the customer varies the ACS, LSM, or tape drive offline and back online
When the customer reconfigures the tape drives, LSM, or ACS.
When a tape drive is added or removed, the ACSLS configuration must be updated to add or delete the drive in the ACSLS database.
Updating the ACSLS tape drive configuration avoids errors on mounts and prevents mounting a cartridge in the wrong tape drive.
If tape drives have been moved or replaced in a library, use Dynamic Configuration to update the drive types and serial numbers. If one tape drive is replacing another at the same location, the update does not require customer confirmation. If tape drives are being removed from or inserted into a library, the customer must confirm the configuration change.
Notes:
Make sure all affected components are ready before issuing the config request.
Updating the ACSLS database using Dynamic Configuration is done when ACSLS is enabled. Dynamic Config is non-disruptive, and ACSLS can continue processing requests while the configuration is updated.
After issuing config lsm or config acs, it is a good idea to audit the affected LSM or ACS.
Use Dynamic Configuration utility commands from the Unix command prompt to update tape drive configurations. You must be logged in as acsss.
config drive <panel_id>
If the change only affects the tape drives on a single panel or SL8500 rail, use config drive <panel_id> to update the drive configuration for all tape drives on the panel.
config lsm <lsm_id>
Use config lsm <lsm_id> to update the drive configuration for all tape drives in an SL3000 with two drive panels.
Note:
config lsm <lsm_id> also updates the CAPS and storage capacity in the LSM, and should be followed by auditing the LSM.config acs <acs_id>
Use config acs <acs_id> to update the configuration for everything in an ACS (for example, an SL8500 library complex).
Note:
config acs <acs_id> also updates the CAPS and storage capacity of the entire ACS, and should be followed by auditing the ACS.An audit updates the ACSLS database to match the actual inventory of library cartridges.
An audit ejects duplicate and invalid volumes. The cartridges have:
An external label that duplicates one already scanned.
A missing or unreadable external label and no virtual label.
An invalid media type.
An invalid volume ID.
ACSLS records any database changes from the audit in the Event Log, and also displays cmd_proc messages during the audit. Audits only apply to LSM storage cells, not to tape drives or CAPs. For information about running an audit, refer to "audit".
You run an audit to:
Create volume information in the database for newly configured libraries.
Add volumes to the database when the cartridges were not entered through the CAP.
Example: You added an LSM to your library, opened the LSM door, and manually added cartridges to the LSM.
Resolve discrepancies between the library and the database.
Example: Run an audit if you opened an LSM door and manually removed cartridges instead of ejecting them through the CAP. The audit either marks the volume absent or deletes the removed volumes from the database.
Audit an SL3000 after it is configured or reconfigured to ACSLS. The library reports the potential cell locations that are not accessible to ACSLS when ACSLS audits it. Inaccessible cell locations include:
locations where CAPs, drives, and operator panels are installed.
cell locations that the robots cannot access.
cell locations that are not activated.
cell locations that are not in this partition.
Audit intervals depend on several factors, including: your ACSLS configuration; whether the library is reporting cell contents from its database or by examining each cell; your library configuration; the number of database changes required; and the scope of the audit. The following table describes how the differences in the scope of an audit affect the audit intervals.
Table 7-1 How the Scope of an Audit Affects the Audit Interval
| This audit takes less time | Than this audit |
|---|---|
|
A diagnostic ACS/LSM |
An online ACS/LSM |
|
An ACS/LSM dedicated to the audit |
An ACS/LSM processing other requests |
|
A full panel |
A (partially or completely) empty panel |
|
A drive panel |
A standard panel |
|
An inside panel |
An outside panel |
In addition, consider the LSM type for the component you audit. The average audit time for an SL8500 or SL3000 LSM is five minutes (if the SL8500 physical audit completes before the ACSLS audit).
The SCSI Media Changer (mchanger) is the device driver that communicates between ACSLS and any SCSI library. An mchanger must be created for each SCSI or fibre-attached library that is connected to ACSLS.
For more information, see "Adding the SCSI mchanger Device Driver".
The following sections provide information about using the Extended Store Feature.
Note:
This feature does not apply to a single LSM without a pass-thru port.When a cartridge is mounted, its ”home location” is the storage cell from which it was mounted. Normally, when a cartridge is dismounted and its home location is in a different LSM than the drive, ACSLS attempts to assign a new home location in the closest LSM (the shortest pass-thru distance from the tape drive). This is called ”floating” a cartridge to a new home location.
ACSLS attempts to return a cartridge to its home location after a dismount if that home location is in an LSM that is enabled for the Extended Store feature.
Note:
Events such as the volumes' home LSM being offline or a label mismatch on a dismount may prevent ACSLS from returning a cartridge to its home location. If such an event occurs, the cartridge is stored as close as possible to the LSM from which it was dismounted.If you have an Extended Store LSM that you use for cartridge archive, this feature helps to ensure that cartridges from that LSM return to their home locations in that LSM. For example, if Extended Store LSM 3 is enabled for this feature and a cartridge from LSM 3 is mounted on a drive attached to LSM 1, after the cartridge is dismounted, ACSLS attempts to return the cartridge to its home location in LSM 3. If LSM 3 is not enabled, ACSLS tries to store the cartridge in a new cell in LSM 1.
You can only enable entire LSMs for this feature. You cannot enable LSM subcomponents, such as a panel or individual cell. To enable an entire ACS for this feature, you must enable each LSM in the ACS.
Note:
Enabling the Extended Store feature will increase pass-thru activity when cartridges are dismounted. This may significantly decrease library performance.To enable an LSM for the Extended Store feature, modify the lsm_fixed_volume file (found in the $ACS_HOME/data/external/fixed_volume directory). After you modify the file, stop and restart ACSLS to enable the specified LSMs.
Use the following conventions when you modify the sample file:
Comment and blank lines are allowed throughout the file.
Each LSM identifier line consists of the ACS number, followed by a comma, followed by the LSM number. No spaces or tabs are allowed between the ACS number and the LSM number.
Each LSM identifier must be on a separate line.
No explicit ordering of the LSM identifier lines is required.
No explicit end-of-file delimiter is required
Example of the Extended Store Feature Control File:
# This lsm_fixed_volume file must be found in the # $ACS_HOME/data/external/fixed_volume # directory. This is a sample lsm_fixed_volume file that may be # edited your particular configuration. # Comments may appear anywhere in this file, but must include a # pound sign in the first column. # Blanks lines are also allowed throughout the file for # readability, and # will be ignored. # For all the LSM identifiers found in this file, a ”best” attempt # will be # made to return the volume to its home location at dismount. # A valid LSM identifier consists of the ACS number, separated bya comma, # and followed by the LSM number. Leading or trailing blanks are # ignored. # ACS,LSM # 0,0 # 0,1 # ACS 1, LSM 0 through 3 # ACS,LSM # 1,0 # 1,1 # 1,2 # 1,3
The following example is of a modified control file. In this example, the comment (#) character has been removed from the lines shown in bold to specify that LSMs 0,0 and 0,1 are enabled.
# This lsm_fixed_volume file must be found in the
# $ACS_HOME/data/external/fixed_volume
# directory. This is a sample lsm_fixed_volume file that may be
# edited your particular configuration.
# Comments may appear anywhere in this file, but must include a
# pound sign in the first column.
# Blanks lines are also allowed throughout the file for
# readability, and
# will be ignored.
# For all the LSM identifiers found in this file, a ”best” attempt
# will be
# made to return the volume to its home location at dismount.
# A valid LSM identifier consists of the ACS number, separated by a comma,
# and followed by the LSM number. Leading or trailing blanks are
# ignored.
# ACS,LSM
0,0
0,1
# ACS 1, LSM 0 through 3
# ACS,LSM
# 1,0
# 1,1
# 1,2
# 1,3
With mixed-media, ACSLS supports a mixture of tape drive and media (cartridge) types in the same library. ACSLS mixed-media support prevents the robot from mounting incompatible media types in a tape drive. For example, in an SL8500, the robot will not mount an LTO cartridge in a T10000 tape drive.
ACSLS mixed-media support requires Media ID labels with media characters on cartridges.
Note:
Refer to the ACSLS Product Information Guide for the current list of drive types, media types and drive-to-media compatibility supported.ACSLS has limited knowledge of the recording format used on cartridges. ACSLS does not have access to the data path to tape drives, so ACSLS cannot detect and prevent recording format incompatibilities. However, recent T9840 and T10000 tape drives report the media recording format on a dismount. ACSLS saves this information in the database, and it can be displayed with the command:
display volume [vol_id(s)] –f recording_format_family recording_format_model
For more information, refer to "display volume".
The drives_media.sh utility displays the drive types, media types, and drive-to-media compatibility settings currently supported by ACSLS. As support is added for new drives and media, they are displayed.
To display the ACSLS Mixed-Media settings, enter:
drives_media.sh
The information writes to the screen (standard output).
To output the ACSLS Mixed-Media settings to files in the /tmp directory, enter:
drives_media.sh -f
The information will be written to three files. (If the files already exist, they will be overwritten.)
/tmp/drive_types.txt /tmp/media_types.txt /tmp/media_compatibility.txt
Note the following restrictions for SCSI-attached LSMs:
Because some tape drives do not support dynamic write-protect settings are through the control path, you must use caution when mounting cartridges using the ’read-only' option. All StorageTek drives support this feature. For non-StorageTek drives, you are advised to confirm that dynamic write-protection is supported. Specifically, LTO drives do not support the ”read-only” option.
Unless the drive supports this feature, you run the risk of losing data on cartridges that you assumed are to be mounted with the write-disable protection of a read-only mount.
Automatic-cleaning operations in SCSI-attached libraries is handled by the library microcode and not by ACSLS. The library control panel provides a menu for users to enable library control of automatic-cleaning operations. For more information, see your library documentation.
You can select a normal load or fast load option through the library. Not all tape management systems, however, support the fast load option.
On scratch mount requests you can explicitly specify the media type you want to use, or you can have ACSLS select a media type.
In order for ACSLS to select a media type, you must pre-define a prioritized list of compatible media types for each drive type. This list is referred to as the ”scratch preferences.”
There is one set of preferences for the entire server; preferences are not defined by client.
If a compatible media type is not listed for a drive, the media will not be selected.
The following sections describe the user and system defined files that ACSLS uses in determining scratch preferences.
The following are the user-defined mixed-media files that are located in $ACS_HOME/data/external/mixed_media/:
scratch_preferences.dat
User-defined preferences file. Primary source of preference definitions.
scratch_preferences.SAMPLE
Sample preferences file can be copied to create the scratch_preferences.dat file.
Display the ACSLS mixed-media settings using drives_media.sh -f
Review the media compatibility settings saved in:
/tmp/media_compatibility.txt
This is the system-defined compatibility settings file. It is used only if the user-defined preferences file does not exist or is missing a drive type
/tmp/drive_types.txt
System defined list of supported drive types.
/tmp/media_types.txt
System defined list of supported media types.
The following table describes how ACSLS uses the mixed-media files to select a media type for a scratch mount request.
Table 7-2 How ACSLS Uses Mixed-Media Files
If the scratch_preferences.dat file ... |
ACSLS does this... |
|---|---|
|
Does not exist. |
Uses the definitions from the system |
|
Lists more than one media type for a drive. |
Selects the media types in the order listed. |
|
Lists no media type for a particular drive. |
Uses the data from the system |
|
Does not list a particular drive type. |
Uses the data from the system |
Use this procedure to define a scratch_preferences.dat file, which contains an ordered list of scratch cartridge types to select for given drive types. ACSLS uses this file for mount * command where a media type is not explicitly specified.
The following example shows the contents of the scratch_preferences.SAMPLE.
Drive Type Name Media Type Preference Name 4480 3480 SD3 DD3A SD3 DD3B SD3 DD3C
To define a scratch preferences file, do the following:
Log in as acsss.
Change to the external mixed media directory:
cd $ACS_HOME/data/external/mixed_media
Copy the sample scratch preferences file to create the user-defined file:
cp scratch_preferences.SAMPLE scratch_preferences.dat
Using a text editor such as vi, modify the list of preferences in the scratch_preferences.dat file:
Follow the instructions in the comments at the top of the file.
If you want to use more than one media type for a drive type, enter each media type on a separate line; the order of preference is from top to bottom.
Save the file.
From cmd_proc, restart ACSLS:
start
Dual TCP/IP is an option that can be purchased for the SL8500 and SL3000. It provides two TCP/IP connections to the libraries. However, you can continue to use the libraries with only one of the two connections operational.
The purpose of dual TCP/IP is to automatically recognize and avoid a failing communication path. Since this is automated, there is no need for you to manually switch from an inoperative connection. For more information, see "Dual TCP/IP Support".
ACSLS 5.2 and above supports dual-LAN client configurations, which consist of a primary LAN and a secondary (backup) LAN. If the primary LAN fails, the client switches to the secondary LAN. ACSLS removes all outstanding messages to that client and begins communicating using the secondary LAN. Because ACSLS removes all outstanding messages before switching over to the secondary LAN, a client will not receive a success message even though a request completed successfully.
For example, a client requests ACSLS to eject ten cartridges. ACSLS starts ejecting the cartridges, then communications fail between ACSLS and the primary client LAN. ACSLS removes all outstanding messages to that client and begins communicating through the secondary LAN. ACSLS successfully completes ejecting all ten cartridges, but sends no success message to the client. The client must verify that the request completed successfully. In this example, if the client issues a query volume request against the IDs of the ejected volumes, ACSLS returns a volume not found error message, which confirms that ACSLS ejected the cartridges.
ACSLS ensures that any transient requests complete successfully if a LAN communications switch over occurs. After switch over, however, the client must cancel any persistent outstanding requests (such as CAP operations) originally submitted on the primary LAN and resubmit these requests through communications from the secondary LAN. Resources (such as, CAPs, locks, drives, and so forth) allocated through primary LAN communications will remain allocated after switchover to the secondary LAN.
The following sections tell how to configure ACSLS for dual-LAN client operations by doing the following:
Register the IP addresses of primary and secondary LANs by creating a csc_ip_switch.dat file
Install a second ethernet port for a multi-homed ACSLS server
Set the TCP/IP connection timeout interval to decrease the system switchover time to the backup LAN.
To register the IP addresses of the primary and secondary LANs with ACSLS, create the file csc_ip_switch.dat in the $ACSSS_HOME/data/internal/client_config/ directory. The following is an example of a csc_ip_switch.dat file.
#The following entry is System Zed's primary and secondary LAN IP addresses. 129.80.30.40 129.80.30.50
As shown in the example above, the # sign precedes a comment. The entries consist of a client system's primary LAN IP address in the left column followed by one or more blanks, then a client systems' secondary LAN IP address in the right column. In this example, System Zed's primary LAN IP address is 129.80.30.40 and its secondary LAN IP address is 129.80.30.50.
After you create or update the csc_ip_switch.dat file, if ACSLS is running, you must stop and restart ACSLS.
If ACSLS successfully reads the csc_ip_switch.dat file on restart, ACSLS logs the success message 2010 I DUAL PATH OPTION ACTIVATED in the he ACSLS Event Log. Otherwise, dual-LAN support is not activated.
This section describes the procedure for installing a second ethernet port for a multi-homed ACSLS server. The second ethernet port provides the attachment to the second control path adapter, which controls the backup LAN. This procedure requires the SBUS Buffered Ethernet card. You can order this Ethernet card from Oracle as part number X1053A.
The installation procedure includes:
Installing the hardware and rebuilding the kernel
Defining a host name for the new ethernet port
Creating the /etc/notrouter file
To install a second ethernet port, do the following:
Install the SBus Buffered Ethernet card according to the manufacturer's instructions.
Reconfigure the system kernel for the new device:
Power the system on. When it begins to boot, press [[STOP]]-[[A]] to enter the PROM monitor.
At the ok prompt, boot the server:
boot -r
When the boot has completed, login as root.
Create a hostname for the second ethernet port.
echo 2nd_host_name > /etc/hostname/hme1
Where 2nd_host_name is the hostname for the second ethernet port.
Enter the following command:
touch /etc/notrouter
This creates the /etc/notrouter file.
Reboot the server:
reboot
This completes the procedure.
The UNIX system variable tcp_ip_abort_cinterval sets the TCP/IP connection timeout interval between the client and the ACSLS server. Changing the default value (180 seconds) of this variable may decrease the switchover time to the backup LAN. Note, however, that actual switchover time depends on the configuration and type of failure.
For example, if an ACSLS server port fails and multiple clients are communicating through this port, ACSLS serially recovers communications with each client. Multi-client recovery for a failing port therefore takes longer than recovery with a single client communicating with a failing port.
To decrease the switchover time to the backup LAN, do the following:
Log in as root on the ACSLS server.
From the prompt, enter the following command:
/usr/sbin/ndd -set /dev/tpc tcp_ip_abort_cinterval 15000
This command changes the TCP/IP connection timeout interval to 15 seconds (the default is 180 seconds).
HINT: To make this command persistent (across server reboots), add the command to the /etc/rc2.d/S69inet file in the ”Set configurable parameters” section.
Event notification allows tracking of events occurring in tape libraries for ACSAPI clients. This feature is provided by the CSC Toolkit. Specifically, with event notification, the ACSAPI client can do the following:
Register for library resource events and/or volume events
Un-register for these events
Check registration status for library events and be notified when they occur
Client registration requests and event notification messages are delivered to the client until the registration is dropped. Event notification periodically checks the registration status of the client to verify that the client is alive. This avoids sending responses to clients that are no longer active and the unnecessary use of network resources.
The following types of events can be tracked:
Addition and deletion of volumes and when maximum usage is exceeded for cleaning cartridges in the ACSLS database.
Changes in library component status such as an LSM or drive changing from online to offline, diagnostic, or recovery; or a CAP that is opened or closed.
Hardware failures such as an inoperable robotic hand.
ACSLS now restores tape libraries and drives to the availability you desire. This is done by tracking both the current state and the desired state for ACSs, ports, LSMs, and tape drives. When a library or drive is no longer accessible by ACSLS or is inoperative, ACSLS changes its current state to offline. After the library or drive becomes accessible or operative again, ACSLS will automatically recover it and bring it back online if its desired state is online.
Desired state manages library and tape drive availability. Desired state is the availability that you want for an ACS, port connection, LSM, or tape drive. The initial desired state for all library components is online. You can set the desired state through an explicit vary command. (This is a vary from cmd_proc, the ACSLS GUI, or an ACSAPI client. It is not a vary that ACSLS internally generates because of a library status change.) The desired state for library components can be viewed using the query lmu and display commands.
The current state (specified as "state") for an ACS, port, LSM, or drive is the current availability of the component limited by desired state. Current state reflects whether a library component is ready and communicating, limited by the desired state of the component and higher level components.
For example, if the desired state of an LSM is online but it is not ready, its current state is offline. When the LSM comes ready again, the library sends ACSLS a message, and ACSLS automatically recovers the LSM and brings its current state back online.
However, if an LSMs' desired state is offline, ACSLS sets the current state to offline. If the LSM goes not ready and comes back to ready status, ACSLS will leave the LSMs' current state offline.
The current state of a library component cascades down to lower level components.
Specifically, if an ACS is no longer accessible, the current state of the ACS is offline. The current state of all LSMs and drives are also set to offline because they are also inaccessible.
When the desired state of an ACS is changed to offline by a vary command, the current state of the ACS is set to offline, and the current state of all LSMs and drives in the ACS are set to offline.
Likewise, when the current state of an LSM changes to offline, the current state of all drives in the LSMs become offline. The desired state of the drives does not change.
Changing the desired state of a library component does not affect the desired state of lower level components.
Changing the desired state of an ACS does not affect the desired state of the LSMs and drives in the ACS.
Changing the desired state of an LSM does not affect the desired state of the drives in the LSM.
This lets you vary selected drives in an LSM offline to make them inaccessible.You can then vary the LSM offline for maintenance. When you vary the LSM back online, the selected drives remain offline, while the other drives come back online.
Availability of physical libraries and drives affects logical libraries and drives.
The availability of logical libraries and tape drives in logical libraries is also governed by the desired state that you set for both the underlying physical library and the logical library.
If the desired states for both the physical library and logical library are online, the current states of logical libraries and logical tape drives reflect the current state of the underlying physical libraries and drives.
However, if the desired state for the physical ACS or drive is online, but the desired state of the logical library or drive is offline, the logical library or drive remains offline and unavailable.
ACSLS queries mount and dismount requests when temporary library outages are detected. Mount and dismount requests from all sources are automatically queued and retried, if the desired state of all required library components is online. This means mount and dismount requests from the following sources are all automatically queued and retried:
ACSAPI clients
cmd_proc
Fibre-attached clients for tape drives in logical libraries
Temporary outages occur when the desired state of the library hardware is online, but the current state is offline. Examples of temporary outages, are: when an LSM door is open; when ACSLS loses communications with a library; or during an LC switch operation. During a temporary library or tape drive outage, mounts and dismounts are queued, and are retried when the library is available.
If the desired state of the library hardware is offline, then ACSLS fails mount or dismount requests with the appropriate error status.
With ACSLS 7.3.1, two dynamic variables, MOUNT_RETRY_DELAY and MOUNT_RETRY_TIME_LIMIT, were introduced for managing the queuing and retrying of mounts and dismounts. The:
MOUNT_RETRY_DELAY controls how often queued mounts and dismounts are retried or availability of libraries and drives are re-checked.
MOUNT_RETRY_TIME_LIMIT is the time limit to queue and retry mounts and dismounts. After this, requests fail.
You must reconfigure ACSLS to update the drive serial numbers and drive types in the ACSLS database whenever tape drives are swapped between locations or a tape drive in the library is replaced with a different tape drive. You must reconfigure ACSLS to add or remove tape drives when they are inserted into or removed from a library. Adding tape drives to the Media Validation pool removes them from access by ACSLS, and removing tape drives from the Media Validation pool allows ACSLS to access them. In these cases you also need to reconfigure ACSLS.
If a tape drive is replacing an existing drive, the drive type and serial number is not updated until ACSLS reads the tape drive status from the library. This happens at:
ACSLS startup.
When the ACS or LSM goes into a not ready and then ready state, causing ACSLS to recover the library.
When you vary the ACS, LSM, or tape drive offline and back online.
When you reconfigure the tape drives, LSM, or ACS.
When a tape drive is added or removed, the ACSLS configuration must be updated to add or delete the drive in the ACSLS database. Updating the ACSLS tape drive configuration avoids errors on mounts and prevents mounting a cartridge to the wrong tape drive.
If tape drives have been moved or replaced in a library, use Dynamic Configuration to update the drive types and serial numbers. If one tape drive is replacing another at the same location, the update does not require customer confirmation. If tape drives are being removed from or inserted into a library, the customer must confirm the configuration change.
When updating tape drives:
Make sure all affected components are ready before issuing the config request.
Updating the ACSLS database using Dynamic Configuration is done when ACSLS is enabled. Dynamic Config is non-disruptive, and ACSLS can continue processing requests while the configuration is updated.
After issuing config lsm or config acs, it is a good idea to audit the affected LSM or ACS.
Issue these Dynamic Configuration utility commands from the Unix command prompt to update tape drive configurations. You must be logged in as acsss.
config drive <panel_id>
If the change only affects the tape drives on a single panel or SL8500 rail, use config drive <panel_id> to update the drive configuration for all tape drives on the panel.
config lsm <lsm_id>
Use config lsm <lsm_id> to update the drive configuration for all tape drives in an SL3000 with two drive panels.
Note:
config lsm <lsm_id> also updates the CAPs and storage capacity in the LSM, and should be followed by auditing the LSM.config acs <acs_id>
Use config acs <acs_id> to update the configuration for everything in an ACS (such as an SL8500 library complex).
Note:
config acs <acs_id> also updates the CAPs and storage capacity of the entire ACS, and should be followed by auditing the ACS.Media validation allows customers to verify all T10000 tape cartridge types using SLConsole or StorageTek Tape Analytics (STA). A dedicated ”media validation pool” of T10000C and T10000D drives is used. The drives in the media validation pool are not available to ACSLS. If the drives were previously configured to ACSLS, the library reports them as ”drive not installed” if ACSLS tries to access them.
When the drive is removed from ACSLS control and added to the media validation drive pool, the LSM (SL8500 rail or SL3000 library) that contains the drive first goes Not Ready and then Ready to the ACSLS. ACSLS also receives a Configuration Changed message from the library.
An ACSLS host automatically updates the drive to an offline state. If the drive will remain in the media validation pool, use the config drives <panel_id> utility to remove the drive from the ACSLS configuration.
Note:
config drives can be run while the library is online and mounts and dismounts to other drives are occurring.After removing a drive from the media validation pool:
For a nonpartitioned library, the drive slot is immediately available to ACSLS.
For a partitioned library, a drive slot removed from the validation pool is not allocated to a partition. Use SL Console to assign the drive slot to a partition.
When the drive is removed from the media validation drive pool and available to the host, the library sends a Configuration Changed message to ACSLS.
If the drive is in the ACSLS configuration, vary the drive online. If the drive is not in the ACSLS configuration, add it with the config drives <panel_id> utility.
Note:
config drives can be run while the library is online and mounts and dismounts to other drives are occurring.