This chapter discusses the following ACSLS utilities:
"acs_partition.sh" enables you to change the library partition identifier for a given ACS in your library complex without having to reconfigure the attached library.
"acs_renumber.sh" enables you to change the identifier of a given ACS in your library complex without having to reconfigure the attached libraries.
"acs_rewallet.sh" allows you to change the user name and password information stored in the ACS wallet for any SL4000 ACS.
"The acsss Macro" starts and stops ACSLS, as well controls and monitors for maintenance and troubleshooting.
"bdb.acsss" backs up the ACSLS database and ACSLS control files.
"Dynamic Configuration (config) utilities" dynamically implements configuration changes to ACSLS libraries (and components) while ACSLS remains online and running. These configuration utilities are:
"config acs" dynamically adds an ACS or reconfigures an existing ACS and its components.
"config drives" - on existing drive panels, it dynamically adds drives, changes drive types, and deletes drives.
"config lsm" dynamically reconfigures an existing LSM and all of its components. These components include CAPs, panels, and drives.
"config ports" dynamically reconfigures the port connections to an ACS.
"db_export.sh" exports the ACSLS database information and ACSLS control files in preparation for an upgrade installation or reinstallation of ACSLS.
"db_import.sh" imports the ACSLS database information and ACSLS control files exported when you used the db_export.sh utility.
db_restore
"del_vol" deletes a volume from an offline LSM.
"drives_media.sh" displays all drive types, media types and the drive-to-media compatibilities that are supported by the current release of ACSLS.
"ejecting.sh" conducts mass eject operations quickly and efficiently.
"free_cells.sh" allows you to monitor and manage the free cells in libraries controlled by ACSLS.
"getHba.sh" manages Fibre Channel HBA ports.
"greplog" filters the acsss_event log to include or exclude messages containing specific keywords.
"install_scsi_Linux.sh"creates /dev/mchanger links which can be used when configuring libraries to ACSLS.
"lib_type.sh" returns the LSM type of the LSMs attached to the specified ACS ID.
"moving.sh" moves multiple cartridges to one or more LSMs.
"probeFibre.sh" displays the model number, revision level, and Target-LUN address of each device connected behind an Emulex (LP10000) or QLogic (QLA2300) fibre-channel HBA.
"rdb.acsss" restores the ACSLS database and ACSLS control files.
"showDevs.sh" shows detail for every mchanger device configured on Solaris.
"showDrives.sh" presents a list of all configured drives attached to ACSLS.
"stats_report"gathers library volume statistical information.
"userAdmin.sh" administers ACSLS GUI user passwords. You can add users, remove users, list users, and change user passwords.
"volrpt" creates a volume report.
"watch_vols" automatically assigns ownership and pool association to volumes as they are entered through the CAP.
Follow these general guidelines for using the ACSLS utilities:
Generally, the utilities described in this chapter are intended for execution by user acsss. To inherit the privileges and environmental dependencies required to run them you should login as user acsss.
If you prefer to use su, be sure to use su - acsss.
It is recommended that you use bdb.acsss to manually back up the database to tape after:
Configuring your library hardware.
Importing the database. After you upgrade to a new version of ACSLS, do not use database backups created with previous versions. Create a new backup as soon as you have upgraded.
Any database recovery.
To ensure that you recover an accurate and consistent database, always use the most current database backup.
If a utility fails, retain all event logs. These logs aid in the support of resolving any problems.
The start and stop scripts that were used in ACSLS 7.x are not supported in ACSLS 8.x.
ACSLS 8.x provided a new mechanism for starting and stopping the library management application, which is integrated with the Solaris Service Management Facility (SMF). This replaces rc.accsss and kill.acsss used in ACSLS. This mechanism also provides the ability to monitor application status.
You can start and stop ACSLS 8.x with the acsss command. The single command acsss provides ACSLS startup, shutdown, and monitoring functions. The utility resides in the $ACS_HOME directory and is accessible to any user.
The following section describes the ACSLS utilities.
This utility enables you to change the library partition identifier for a given ACS in your library complex without having to re-run ACSLS configuration utilities. You can update more than one ACS at a time, as the utility prompts you for each configured ACS.
Note:
This utility is introduced in ACSLS 8.5.1.
This utility is not used to switch an ACS to a different partition. It reflects an update to partition numbers on the library side. The new partition identifier must refer to the same library.
You must disable, but not shut-down ACSLS before running this utility script. The acsdb service must be online. The command acsss status indicates the state.
To change the library partition id associated with an ACS, run the acs_partition.sh script. In an interactive session, you are first reminded about the note above and you are then prompted whether to continue.
$ acs_partition.sh ************************* N O T I C E ***************************** * This utility can update the partition id for a configured ACS, * * but the new partition id MUST refer to the same actual library * * partition. To manage a different partition, re-configure ACSLS. * ******************************************************************* Continue...? (y or n): y
If you respond y, the routine automatically backs up the existing database before any changes are made. This allows you to restore to the previous configuration, should it be necessary to back out of the change. You can also reverse the change if needed, by repeating the acs_partition.sh routine.
The routine displays a list of the currently configured ACSs and, for each one, it asks whether to change the partition id for that ACS. If you do, it asks what new value to assign.
Current ACS list: ACS=0 PORT=0 TYPE=SL4000 PARTITION=1 LIB=https://keystone13 ACS=1 PORT=0 TYPE=SL4000 PARTITION=21 LIB=https://keystone13 ACS=2 PORT=0 TYPE=SL4000 PARTITION=1 LIB=https://keystone35 Do you wish to change the partition ID for ACS-0 from 1? (y or n): n Do you wish to change the partition ID for ACS-1 from 21? (y or n): y What is the new partition_id for ACS-1? 12345 Do you wish to change the partition ID for ACS-2 from 1? (y or n): n
Having accepted your input (in this example, your response was to update only ACS-1), the routine asks you to confirm the pending changes.
Fri Aug 9 13:22:34 MDT 2019 Changing ACS-1 from partition 21 to partition 12345. Correct? (y or n): y
If you answer y, the routine carries out all necessary updates to and automatically backs up the database in order to checkpoint the changes that you have made.
Updating table: Changing ACS-1 to partition 12345 1 records /export/home/ACSSS/utils/acs_partition.sh: ACS-1 was changed from partition 21 to partition 12345. Complete! Current ACS list: ACS=0 PORT=0 TYPE=SL4000 PARTITION=1 LIB=https://keystone13 ACS=1 PORT=0 TYPE=SL4000 PARTITION=12345 LIB=https://keystone13 ACS=2 PORT=0 TYPE=SL4000 PARTITION=1 LIB=https://keystone35 Now backing up the database changes ...
This utility enables you to change the identifier of a given ACS in your library complex without having to reconfigure the attached libraries. Since every LSM, CAP, drive and volume in the library is identified in relation to an ACS, this utility updates all of the various database tables so that each library resource aligns with the new ACS ID that you assign.
New logical libraries would use the currently active pattern. For example, if you renumber ACS 0 to 1, then 1001 and 1002 would stay as they are, but a new logical library in ACS 1 would be 2001. If you then renumber ACS 6 to ACS 0, 7001 would stay as it is, but a new logical library in ACS 0 would be 1003. There is no real correspondence anymore, although newly-added ones would be predictable based on ACS.
Note:
Changes made by this utility apply only to the ACSLS server and not to the client applications that use these resources. Consequently, it may be necessary to reconfigure any client databases after having changed the ACS i.d. on the server.Note:
ACSLS must be disabled before running this script.To change the assigned number of an ACS, run acs_renumber.sh. In an interactive session, you are first warned that the changes made impact any client applications and you are then prompted whether to continue.
$ acs_renumber.sh
N O T I C E
Changes made by this script will
impact client applications that
use ACSLS. Specifically, drive
i.d. mappings and LSM id's will change.
Continue...? (y or n):
If you respond y, the routine automatically backs up the existing database before any changes are made. This allows you to restore to the previous configuration, should it be necessary to back out of the change. (You can also reverse the change by repeating the acs_renumber.sh routine.)
The routine displays a list of the currently configured ACSs and, for each one, it asks whether to renumber that ACS. If you do, it asks what new value to assign.
Current ACS list: ACS-0 (SL8500) Do you wish to renumber ACS-0? (y or n): What is the new value for ACS-0? 5
Having accepted your input (in this example, your response was 5), the routine asks you to confirm the pending change.
Change ACS-0 to ACS-5. Correct? (y or n):
If you answer y, the routine begins updating all of the related database tables and automatically backs-up the database in order to checkpoint the changes that you have made.
Updating tables: Changing ACS-0 to ACS-5 acstable: 1 records captable: 4 records celltable: 13424 records drivetable: 128 records handtable: 16 records lmutable: 0 records lsmtable: 8 records paneltable: 280 records porttable: 1 records ptptable: 16 records scr_distr_table: 0 records volumetable: 0 records Complete! Current ACS list: ACS-5 (SL8500) Now backing up the database changes...
The acs_rewallet.sh utility re-creates the wallet for an SL4000 ACS, allowing you to change the user name and password information stored in the ACS wallet. This is helpful when the ACS wallet becomes corrupt, is accidentally removed, or when library changes the authentication profiles of the partitions as per their compliance or security policies.
Note:
ACSLS must be disabled before running this script. If an active ACSLS is detected, the utility directs you to stop ACSLS withacsss disable. The utility then exits.To change the user name and password information stored in the ACS wallet, run
acs_rewallet.sh. In an interactive session, you are first warned that the changes made impact any client applications and you are then prompted whether to continue.
$ acs_rewallet.sh ************************* N O T I C E ************************** * Changes made by this script will NOT impact client * * applications that use ACSLS. * **************************************************************** Continue...? (y or n):
If you respond y, the routine displays a list of the currently configured SL4000 ACSs:
Only SL4000 ACSs require secured access, and hence need authentication profile. Current SL4000 ACS list: ACS-0 (SL4000) ACS-1 (SL4000)
For each ACS listed, the routine asks whether to regenerate the wallet for that ACS. If you respond y, the routine prompts you to enter a username once and password twice (to verify your new password), and then recreates the wallet with the same name:
Do you wish to regenerate wallet for ACS-0? (y or n): y ACS #0 : Interview for Authentication Profile Enter User Name for ACS #0 : admin Enter Password for ACS #0 (1st Time) : ********* Enter Password for ACS #0 (2nd Time) : ********* ACS #0 : Wallet creation successful. ------------------------------------------------- Recreate authentication profile for ACS-0...DONE Regeneration of ACS wallet was successful. Do you wish to regenerate wallet for ACS-1? (y or n): y
This is a critical operation. Make sure that all wallets are regenerated correctly.
A single wallet with an incorrect authentication profile will prohibit ACSLS from starting, as shown in the following example:
$ acsss enable Enabling ACSSS: WebLogic starting... acsdb enabled. acsls starting: [!!!!!!!!!!!!!!!!] acsls terminated! + exit 1 Problems starting ACSLS! Details are logged toward the bottom of the ACSLS event log and the SMF start log: logfile /export/home/ACSSS/log/acsss_event.log logfile /export/home/ACSSS/log/acsls_start.log Disabling ACSSS: acsls disabled. surrogate disabled. rmi-registry disabled. acsdb disabled. weblogic disabled.
The acsss macro is the primary start, stop, and status command that launches and brings down the various services associated with ACSLS. Depending on the installation, an ACSLS application is an aggregate consisting of up to seven services that are installed on the Solaris or Linux system.
acsdb - manages the ACSLS library database.
acsls - library control software that executes library operations.
weblogic - web server for the ACSLS GUI.
surrogate - communication link between java services and acsls.
rmi-registry - lookup service for named java objects and methods.
smce - SCSI Media Changer Emulation of logical libraries.
stmf - target mode framework for logical libraries.
The acsls and acsdb services are common to all installations. The weblogic, surrogate, and rmi-registry services are present where the ACSLS GUI support has been configured. The smce and stmf services apply only if logical libraries have been configured (on Solaris).
All of the services are manipulated by the ACSLS user with the single macro, acsss, which starts and stops these services in a defined sequence required by dependencies between the different components.The macro issues commands to the Service Management Facility (SMF) on Solaris and the init.d service utility on Linux to undertake the actual work.
| Command | Function |
|---|---|
enable |
This is the default method to launch all the services associated with ACSLS. Once enabled, the various services remain enabled and will be re-enabled automatically after a system reboot. |
temp-enable |
Same as acsss enable but services are not restarted after a system reboot. |
maint-enable |
Intended for general maintenance operations not involving the ACSLS database. This option enables the GUI infrastructure allowing GUI users to remain logged in while ACSLS is disabled. This method is used in contexts of minor software patch installations. Neither the acsls nor the smce service is enabled. |
db |
This is the preferred control mode to use for database maintenance operations including db_export, db_import and acsss_config. It enables the ACSLS database engine and disables all other ACSLS services including the ACSLS GUI. |
disable |
This is the default method used to halt ACSLS operation. It is not a complete shutdown and allows for the database and any GUI login sessions to remain active for maintenance operations after the acsls and smce services have been disabled. The resulting state is identical to that of acsss maint-enable. This is the safest method to bring down the server since ACSLS and the library are placed in an idle state before the services are disabled. |
force-disable |
Same as acsss disable but the operation does not wait for an idle state before disabling acsls and smce. |
shutdown |
This renders a complete shutdown of all ACSLS services. It is intended for contexts of software installation and de-installation, and other maintenance contexts that require the database (acsdb) or the GUI infrastructure (rmi-registry and surrogate) to be shutdown. |
status |
Provides a quick status report of the various ACSLS services. |
a-status |
Returns the operational status of the acsdb service. |
d-status |
Returns the operational status of the acsls service. |
g-status |
Displays the status of the ACSLS GUI. |
l-status |
Provides a verbose status summary of the various ACSLS services and includes pointers to log data for further analysis in troubleshooting contexts. The logs to which it points are helpful in contexts where the service failed to start up or shutdown. |
p-status |
Similar to acsss status, this report includes a listing of the various process IDs that are monitored by each respective service contract. |
w-status |
Shows the status of the weblogic service. |
timeout |
Reports the SMF start-up timeout for the acsls service on Solaris. |
legal |
Displays the ACSLS Legal Notice in English or French. |
In most cases, you use only the top three commands: enable, disable, and status. The remaining commands are for convenience in contexts of servicing the software.
The bdb.acsss utility backs up the ACSLS database contents and ACSLS control files that you must rebuild the ACSLS environment. The backup is either placed in a tar file or tape device you have named, or in the directory defined as the default.
This utility performs ACSLS database backups without requiring ACSLS to be down (hot backup).
Without the -f option, a /export/backup/<time_stamp>.tar file is created. time_stamp is the time the bdb.acsss command was executed. To verify the contents of the tape after running bdb.acsss, modify the following examples for your specific tape devices.
For Solaris:
tar tvbf 2048 /dev/rmt/0mn
After running the tar tvbf command, the tape advances to the next block. Make sure you have rewound or re-positioned the tape if you intend to run rdb.acsss after running the tar tvbf command.
bdb.acsss [-f backup_file | tape_device]
If you enter bdb.acsss with no options, a default backup is performed that provides you the ability to restore the database back to the time when this backup was performed.
-f backup_file
specifies a UNIX file to contain the ACSLS database backup. You must have write permissions to the file and directory.
-f tape_device
specifies any tape device attached and configured to the ACSLS server.
Use the bdb.acsss utility to back up the ACSLS database to tape or to an external network file to create backups that can be used, if needed, for recovery of the database.
It is recommended that you use bdb.acsss to manually back up the database after:
Running acsss_config.
Importing the database. After you upgrade to a new version of ACSLS, do not use database backups created with previous versions.
An audit of the entire library.
Any database recovery.
Example 1:
$ bdb.acsss -f /export/backup/my_backup
In this example, a file named my_backup was created in the directory
/export/backup. You can now choose whether to keep the file, where it is located, or if to move it to another file system, another server, or a writable CD device.
This file can then be used to restore the database to the state it was in when the backup was performed. For example, if the backup was performed at 1:00 pm on Friday and a restore is performed at 6:00 am on Monday, the database will revert back to its state as of 1:00 pm on Friday.
Within this same -f option, you can give a tape device instead of a file name and the backup will go to the named tape device.
Example 2:
$bdb.acsss -f /dev/rmt/0mn
In this example, a tape archive on the tape device /dev/rmt/0mn was created. This can be stored for later use in an offsite location.
See also:
The dynamic configuration (config) utility allows you to implement configuration changes to ACSLS libraries (and components) while ACSLS remains online and running. These configuration changes are recorded in the acsss_config.log file.
The following dynamic configuration utilities are supported:
config acs
config drives
config lsm
config ports
Using the config utility provides the following benefits:
ACSLS can continue running, allowing you to perform mount requests to unaffected library components.
Allows you to reconfigure specified library components while all other configuration information remains unchanged. For example, when specifying:
an ACS, the configurations of other ACSs are not affected.
an LSM, the configurations of other LSMs are not affected.
a drive panel, the drives on a panel, mounts and dismounts to all existing drives are not affected.
It is important to recognize the following points:
ACSLS must be running to use the dynamic config utility.
You must use acsss_config to create your initial ACSLS configuration. Refer to "Setting Variables that Control ACSLS Behavior".
Event notification reports all dynamic configuration changes.
Before running dynamic configuration, ensure that all components being added or reconfigured are ready.
The acsss_config.log file provides details regarding messages displayed.
If you have not confirmed the configuration change, you can cancel the operation with [[CTRL]]+C.
Dynamic configuration performs an automatic backup before and after the configuration change.
After a configuration change is confirmed, it cannot be canceled. If you want to reverse a configuration change, shut down ACSLS and restore the backup that was taken immediately before the configuration change was made.
You have 10 minutes to confirm a configuration change before it times out.
You cannot remove the only (or last) ACS.
Do not remove the last CAP in an ACS or the last drive defined to ACSLS.
The dynamic configuration utility has two significant limitations:
You cannot delete an ACS, delete, or change a port (connection) to a library.
With an existing SCSI/fibre-attached library, you can only update drive configurations in config acs and config lsm utilities. Panel or CAP configurations are not updated. The config drives and config acs new works with SCSI/fibre-attached libraries without limitation. The config ports utility is not supported on a SCSI/fibre-attached library.
Solution:
For these configuration changes that are not supported through dynamic configuration, you must bring down ACSLS and use acsss_config.
Do not use dynamic configuration to display status information for a library and its components because it involves extensive I/O to the library
Use the query or display commands instead.
Do not attempt to perform more than one configuration task at a time.
Only one dynamic configuration task can be performed at a time. This:
Minimizes performance problems caused by the I/O between ACSLS and the library it is configuring
Avoids complex interactions between multiple configuration tasks.
The config acs utility allows you to:
Add an ACS or reconfigure an existing ACS and its components
You can configure or reconfigure libraries without assigning all ACS numbers in sequence.
Example: You want to migrate from an SL8500 library to an SL8500 and then remove the SL8500 library. The SL8500 library is numbered ACS 0 and the SL3000 library is ACS 1. Using config acs, you can now migrate all of the cartridges and drives to the SL3000 library and later remove the SL8500 library without having to renumber your SL3000.
Add the SL3000 library with config acs acs_id new without shutting down ACSLS.
Move drives from the SL8500 library to the SL3000 library and update the drive configurations in both ACSs with config acs acs_id .
Remove cartridges from the SL8500 and enter them into the SL3000 library.
Finally, schedule an outage to shutdown ACSLS and remove the SL8500 from the configuration using acsss_config. Do not configure the SL8500. Remember to specify that the SL3000 is ACS 1 (not the default of zero).
Configure a partitioned ACS.
Add or remove LSMs, since the config lsm utility only allows you to reconfigure an existing LSM.
Each ACS must have at least one CAP. This can be a CAP that is shared with another partition. There must be at least one drive configured to the entire ACSLS system.
For example, if ACSLS supports four libraries three of the libraries can contain zero (0) drives. However, the fourth library must contain at least one drive.
To add a new ACS, enter the following command:
config acs new
To reconfigure an existing ACS, enter the following command:
config acs acs_id
To add a new ACS:
Enter the following command:
config acs new
Specify the ACS number for the new ACS.
ACSLS lets you configure or reconfigure libraries without assigning all ACS numbers in sequence.
The ACS numbers already used and the first five available ACS numbers are displayed.
Enter the ACS number for your new ACS.
Select whether the ACS is in a partitioned SL8500 or SL3000.
If you enter y, you are asked for the partition ID for the ACS. This partition ID must match the partition ID on the SL Console.
If this is not a partitioned library, or is SCSI/Fibre-attached, enter n.
ACSLS does not support partitioned SCSI/Fibre-attached libraries, such as the SL150. Also, partitioned SCSI/Fibre-attached libraries do not have partition IDs.
Enter the number of connections to the ACS, followed by the device or host ID(s).
You can have a maximum of fifteen connections.
Note:
Ensure that all ports are connected to the same ACS.The new ACS configuration is displayed.
Confirm the addition of the new ACS.
After confirmation, the configuration information is displayed and the database is updated.
The ACS should, if possible, be online or in diagnostic mode when you reconfigure the ACS.
To reconfigure the ACS:
Enter the following command:
config acs acs_id
The old and new configurations are displayed.
Confirm the new configuration.
After confirmation, the database is updated.
If the configuration is unchanged, the configuration is displayed without asking for confirmation, and the utility exits. Examples of this are:
Only drive types and/or serial numbers change
LSM serial number changes
Number of hands, such as SL8500 robots, change.
However, if these changes occur with other changes requiring confirmation, confirm the new configuration. The database is then updated.
The ACS and its components are removed from the database.
With SCSI-attached libraries, config acs updates only the drive configuration. A SCSI-attached library must be IPLed to recognize drives that are added, removed, or changed. All drives must be ready when the library is IPLed.
For a SCSI-attached library, config acs will not update panel or CAP configurations. In order to update them, you must bring down ACSLS and use acsss_config.
The config drives utility allows you to reconfigure all drives on an existing drive panel. This includes, adding drives, updating drive types and serial numbers for existing drives, and deleting drives that were removed from the database.
Use the config drives utility for dynamic changes to drive configurations, which include installation, replacement, or removal of drives on an existing drive panel. Other changes to tape library hardware configurations, such as changes in the number and/or location of storage cells, number or size of CAPs, or replacement of a storage cell panel with a drive panel must be made using the config lsm or config acs utility.
Notes:
The LSM containing the panel with the changed drive configuration must be online or in diagnostic mode.
On the drive panel being reconfigured, all drives must be ready.
A SCSI-attached library must be IPLed to recognize drives that are added, removed, or changed. All drives must be ready when the library is IPLed.
When new drives replace existing drives, varying the LSMs, drive types online or running config drives will automatically update the drive types and drive serial numbers.
To reconfigure all drives on an existing drive panel:
Enter the following command:
config drive panel_id or config drives panel_id
The old and new drive configurations are displayed for the panel.
Confirm the configuration change.
After confirmation, the database is updated.
If the configuration has not changed, the configuration is displayed without asking for confirmation, and the utility exits.
If only drive types or serial numbers changed, the ACSLS database is updated without requesting confirmation.
This utility allows you to reconfigure an existing LSM and all of its components. These components include CAPs, panels and drives.
If you want to add or delete an LSM in an ACS, you must use the config acs utility.
Procedures for when Panels Change:
If there are panels that are being removed or changed and have been emptied of cartridges, the LSM can remain online.
If there are panels that are being removed or changed and contain cartridges, it is recommended that you vary the affected LSM to diagnostic until you reconfigure the LSM and audit the panels affected. If you do not do this, mounts and dismounts may fail.
If you have added panels and have manually placed cartridges in these panels, run an audit to reconcile the database.
To reconfigure the LSM:
Enter the following command:
config lsm lsm_id
The old and new configurations are displayed.
A ”y” next to the panel notifies you that the panel type(s) have changed. Look in the acsss_config.log file for details.
Confirm the new configuration.
After confirmation, the database is updated.
If the configuration is unchanged, the configuration is displayed without asking for confirmation, and the utility exits.
Minor changes are made automatically without confirmation. Examples are:
Only drive types and/or serial numbers change
LSM serial number changes
Only LSM type changes between the 4410 and 9310
Number of hands, such as SL8500 robots, change.
However, if these changes occur with other changes requiring confirmation, confirm the new configuration. The database is then updated.
With SCSI-attached libraries, config lsm updates only the drive configuration. A SCSI-attached library must be IPLed to recognize drives that are added, removed, or changed. All drives must be ready when the library is IPLed.
It will not update panel or CAP configurations. In order to update them, bring down ACSLS and use acsss_config.
The config ports utility allows you to dynamically add port connections to an ACS.
Note:
All new ports must be connected to the same ACS as existing ports.Run config acs acs_id and then config ports acs_id.
To replace one ACS with another ACS or change port connection addresses, bring down ACSLS and use acsss_config.
Enter the following command:
config port acs_id or config ports acs_id
The current port connection for the specified ACS are displayed.
Enter the number of port connections for the specified ACS.
You can have a maximum of fifteen connections.
Specify the device or host ID (s).
Note:
Ensure that new ports are connected to the same ACS as existing ports.The old and new configurations are displayed.
A change in the order of the ports is not a configuration change. The connections are displayed in the order they are currently recorded in the database.
Confirm the new configuration.
After confirmation, the database is updated.
If the configuration is unchanged, the configuration is displayed, and the utility exits.
The db_export.sh utility exports the ACSLS database table data and ACSLS control files in preparation for an upgrade installation or a reinstallation of ACSLS.
Note:
Thedb_export.sh utility cannot run if ACSLS is running. Run acsss disable before running db_export.sh.-f db_file
specifies a UNIX file to contain a backup of the ACSLS database. Write permissions to both the file and directory.
Notes:
If you export the database to a file, the file must reside in a non-volatile directory. If your intention is to re-install ACSLS, the re-installation will destroy the $ACS_HOME or $ACSDB_BKUP (such as /export/backup) directories. Place the exported file elsewhere in your file system.
If you specify the filename without a path, db_export saves the database file under that filename in the current working directory. It saves the ACSLS control files in a file named <filename>.misc in the same directory.
If you are exporting your database to an earlier release of ACSLS that does not support some of your tape libraries, tape drives, or cartridge media types, remove the unsupported tape libraries from your configuration, also the tape drives and cartridges from your libraries before exporting your database.
-f tape_device
specifies any tape device attached and configured to the ACSLS server.
If no options are specified, the system defaults to the tape device.
The db_import.sh utility imports the ACSLS database table data and the ACSLS control files that you exported when you used the db_export.sh utility. The ACSLS control files are located in $ACS_HOME/data/external and consist of user definable variables and configuration for ACSLS. They specify Access Control settings, scratch preferences, Extended Store LSMs, custom volrpt settings, volume attributes (for watch_vols utility), and so on. The db_import.sh utility also provides disaster recovery capabilities and the retention of your customized dynamic variables when moving to a different operating system or from an earlier release.
-f db_file
specifies a UNIX file created by db_export.sh.
-f tape_device
specifies any tape device attached and configured to the ACSLS server.
If no options are specified, the system defaults to the tape device.
The db_restore.sh utility restores the ACSLS database using an existing database backup file.
latest
indicates that the database be restored from the most recent backup stored in $ACSDB_BACKUP_DIR.
backup_filename
specifies the path to a valid backup file to be used for the database restore. To see a list of valid backup files, list the contents of the directory /export/backup.
If no options are specified, the backup will appear in the backup directory which was defined when ACSLS was installed on the system.
Use the db_restore.sh utility to restore the ACSLS database using an existing database backup file.
Note:
The db_restore utility will not run if ACSLS is running. Run acsss disable before running db_restore.sh.
If you do not want to use an existing database, and would rather create a new one, then run accss_config.
The del_vol utility looks for a volume in the library. If it cannot find the volume, del_vol either marks the volume missing or absent, or deletes it from the database, depending on your request.
If all of the referenced locations for the volume cannot be verified (such as the LSM is offline or the drive is not ready), you are prompted to confirm marking the volume absent or deleting it, unless the -n (no_confirm_flag) is on. It the volume is deleted, the volume and information associated with it, such as scratch pool membership and current and pending locks, are removed from the database.
Volume-related information is displayed unless the -q (quiet_flag) has been entered. If multiple options are used, they can be formatted either as separate options, or as a contiguous string.
Before marking a volume absent or deleting it, del_vol asks you to confirm, unless the -n option is specified.
If the volume is in the library, it remains an active volume in the database.
If the volume cannot be located in the library, it is marked absent, unless you specify that the volume should be deleted.
If cells or drives where the volume may be located are inaccessible (because libraries or drives are offline or inoperative), the volume is marked missing, unless you specify that the volume should be deleted.
Notes:
This utility does not delete a volume that is found in the library.
You can use the del_vol utility to remove a volume record without waiting for the expiration of an absent or ejected status.
ACSLS must be running (enabled) to support the del_vol utility.
-n
no-confirm mode; marks absent or deletes a volume that cannot be located without prompting the user for confirmation.
-q
quiet mode; do not print out all information extracted from the database.
-d
deletes the specified volume without waiting for the expiration of an absent or ejected status.
-f
permits you to re-enter cartridges that were stuck in a tape drive. With the -f option, you can delete a volume or mark it absent without verifying if the volume is actually in the library. This permits you to delete from the database a volume that was in a faulty tape drive. Using this option, you can remove the volume from the drive, delete it from the database, then re-enter the volume for normal library use while the drive is being repaired.
vol_id
The volume serial number to be deleted.
Note:
If the volume serial number contains a dollar ($) sign, enclose it in single quotes. For example: del_vol ’AB$001'You can use del_vol to remove a cartridge from an offline LSM and then re-enter it in an online LSM, so it can be automatically mounted.
Remove the cartridge from the offline LSM.
Use del_vol to mark the cartridge as absent.
Enter the cartridge into the online LSM.
ACSLS and the database must be up and running (not idle) to use this utility.
Note:
If you mistakenly delete a cartridge from the database, you shouldaudit the subpanel containing the home cell of the deleted cartridge to re-enter the cartridge into the database. Running del_vol while the system is in recovery can produce unpredictable results. The recovery sequence also happens during a vary LSM online.This routine displays all drive types, media types and drive-to-media compatibility that is supported by the current release of ACSLS. The information is normally displayed to standard output.
Refer to the ACSLS Product Information Guide for the current list of libraries, drive types, media types and drive-to-media compatibility supported.
The ejecting.sh utility facilitates mass eject vaulting operations. Working from a specified list of CAPs and volumes, this utility executes multiple eject operations in parallel until the overall job is complete. Unless the user requests volumes to be ejected in sorted order, this utility ejects each volume to its nearest specified CAP.
Where possible, nearby CAPs with free space are used instead of the closest CAP, if the operation can reduce unnecessary CAP manipulation by the operator. The general approach reduces cartridge movement, eliminates unnecessary LSM pass-thru migration, and reduces the operators' overall workload.
All eject jobs are monitored and summarized in the single shell window where the operation was launched. See the -x option below for use with multiple XTERM windows. Users are advised each time a specific CAP is full and ready for the operator to Remove cartridges from CAP. The operator is notified when the overall operation is complete.
A set of logs showing the results of all eject operations for the past ten days is kept in the $ACS_HOME/log/ejectingLogs directory. Each individual log is identified by a time stamp taken when the operation completes.
Standard: ejecting.sh [-dmox] -c <CAP list> -v <volume list file>
Policy Specification: ejecting.sh [dmox] -p <policy file>
Legacy Format: ejecting.sh <CAP ID> <volume list file>
-c <CAP list>
A list of CAP ID's separated on the command line by spaces. All CAPs in the CAP list must be in the same ACS.
Example: -c 0,1,0 0,1,1 0,5,0 0,5,1 0,9,0
Wildcard expressions using an asterisk (*) are valid to specify all LSMs or all CAPs in an LSM, or both.
Examples:
-c 0,1,* (All CAPs in LSM-1)
-c 0,*,0 (CAP-0 in every LSM)
-c 0,*,* (All CAPs in every LSM)
Only CAPs that are online and available are selected for the operation. When wildcard expressions are specified, only nonzero priority CAPs are selected.
The ACS must be a numeric expression and cannot be referenced by a wildcard.
In larger library contexts, CAP selection can make a big difference with regard to the speed and efficiency of vaulting operations. Specifying too many CAPs may add unnecessary work for the operator to service multiple partially-filled CAPs. Specifying too few CAPS for a given work load can introduce bottlenecks and thereby increase robotics wait time. As a general rule of thumb for large volume lists, the CAPs you choose should be dispersed across the library complex on different rails and in different library modules. When selecting a few CAPs for a large number of volumes, divide the library into regions and choose a CAP located in the center of each region.
-v <volume file>
This is a file specification using full or relative path name to a simple text file. The file should contain a list of VOL-IDs (VOLSERS) representing the volumes to be ejected. Only the volumes that are contained in the same ACS as the specified CAPs will be affected. Mounted volumes will not be ejected.
-p <policy file>
The policy file is specification using a full or relative path name. This text file contains a defined policy for CAPs and volumes. The format of the file includes the word ”caps:” followed by a list of CAPs to use for the operation; and the word "vols:" followed by the full path name of the volume list file.
Example:
caps: 0,1,0 0,1,1 0,5,0 0,5,1 0,9,0 0,9,1
vols: /export/backup/volumes_to_eject.txt
-d
The display option instructs ejecting.sh to show the volume-to-cap assignments before executing the eject operation. You may choose to display the full list of volumes and the CAPs to which they move, or simply display a summary showing how many volumes migrate from each LSM to each CAP.
After viewing the display, you can choose to continue or to abort the operation.
-m
Label the job with an operator message code between "04" and "99". On supported libraries, this numeric code will be displayed on the operator console.
-o
There are times when vaulting operations require volumes to be stacked in a sorted order. With this option, the routine moves the specified volumes to the listed CAPs according to the order they are found in the volume list, and according to the specified CAP order. The CAP order is repeated from the first CAP to the last, until all volumes have been ejected.
Note:
Since volume to CAP order takes precedence, this option makes no attempt to optimize volume movement by limiting LSM pass-thru routes.-x
Use a dedicated XTERM window for each discrete CAP eject payload. You may find this option useful to keep track of individual eject jobs during the overall mass-eject operation. An XTERM session pops up as each CAP eject is launched and disappears when the corresponding eject has completed.
When operating from a Windows terminal, make sure that X11-capable software is installed. X11 is standard on Solaris or Linux. You must open display access control to the ACSLS server from the local machine.
Example: xhost + <acsls_server_hostname>
This utility looks at your login identity (who am i) to determine where to send the DISPLAY. You must login directly from your local console or desktop machine to the ACSLS server in order to see the display.
Legacy Format
ejecting.sh <CAP ID> <volume file>
The legacy form of this utility has been preserved. It takes a single CAP ID and a path name to a file containing a simple list of volumes. It then composes a series of eject commands optimized to the size of the CAP, and displays the resulting commands to standard out. The display includes as many eject commands as are necessary to eject the full volume list through the specified CAP.
The operator can pipe the output of legacy ejecting.sh to directly to cmd_proc to execute the operation.
Example:
ejecting.sh 0,1,0 /export/backup/myVolumeList | cmd_proc -lq
Alternatively, the output can be redirected to a file which can later be redirected to cmd_proc.
Example:
ejecting.sh 0,1,0 /export/backup/myVolList > /tmp/eject.dat cmd_proc -lq < /tmp/eject.dat
Every instance of ejecting.sh is logged in the directory, $ACS_HOME/log/ejectingLogs/.Each log file is named with a date-time stamp. For example:
ejecting.log.14-Oct_13:13:10
Each ejecting.log summarizes the overall ejecting operation as it was seen from the operator shell. Any errors that were encountered are seen here.
An ejecting.log may contain a listing of volumes that are ignored by the utility because:
The volume ID is invalid.
The volume is not contained in the specified ACS.
The volume is in use.
The accumulating files in the ejectingLogs/ directory are purged after ten days. Logs older than ten days are removed with each new invocation of ejecting.sh.
The free_cells.sh utility allows you to monitor and manage the free cells in libraries managed by ACSLS. This utility reports the free cell count for LSM, ACS, and the ACSLS server.
This utility is located in the $ACS_HOME/utils directory
The getHba.sh utility manages Fibre Channel HBA ports.
getHba.sh
The getHba.sh utility is run at install time and is called by install_acsss.sh which is called by install.sh. The utility can be run directly any time a new HBA has been added to the system or any time the HBA ports are re-arranged. This utility identifies an appropriate HBA port to change from initiator to target mode, in order to reveal a client access point to ACSLS logical libraries.
Note:
getHba.sh can only be run if a previous logical library was installed, or the correct target mode package was installed using install.sh. Refer to the ACSLS Installation Guide for information about running install.sh.The best way to use this utility to set up your FC connections before getHba.sh is run. This enables getHba.sh to show you useful information about the existing connections.
The utility first assesses whether a target mode adapter has already been configured. If no target ports exist, the flow of the utility continues as discussed below. If the utility senses any existing target port, it displays the following menu of choices.
Select a desired action:
Keep the existing HBA port configuration.
Configure an additional target-mode port.
Restore an existing target port to initiator mode.
| Option | Description |
|---|---|
| 1 | Exits this utility. |
| 2 | The utility lists the ports that are currently operating in initiator mode. When a port shows "Connected to a remote HBA", it's means there is an initiator at the other end, making it a potential candidate to become an ACSLS target port. When a port shows "Connected to a target device", there is probably a tape library or disk attached, so that port would be a bad choice for target mode operations. |
| 3 | Identifies each port configured for target mode operations and prompts you for confirmation to restore that port to initiator mode. |
Example of Option 2
Select which local HBA port is to be changed to Target mode. Select from the following list:
HBA Port WWN 2100001b32055d85 Not connected.
HBA Port WWN 2101001b32255d85 Connected to a remote HBA.
HBA Port WWN 2102001b32055d85 Connected to a target device.
None of these.
Note:
If you have no intention of using the logical library feature, select "none of these".Once you make the selection, you are asked for confirmation.
2 HBA Port WWN 2101001b32055d85 /pci@0,0/pci10de,377@f/pci1077,143@0 Is this correct? (y or n):
You are given the opportunity to change your mind. If you respond "n,"the list of available ports are again displayed with a prompt for your selection. If you respond ”y,” you are asked if there are additional ports you want to reconfigure.
The utility will proceed to add a target group and a target group member, and you are instructed to reboot the server for the target-mode changes to take effect.
Creating Target Group: 2101001b32255d85
Example of Option 3
This option enables you to unconfigure an existing target and restore the HBA to its native mode as an initiator.
# cd $ACS_HOME/install
# ./getHba.sh
A Target-mode port has already been configured:
Target: wwn.2100001B32050A28
Connected to ...
Initiator: wwn.210100E08BA61A29
Please select a desired action:
1) Keep the HBA port configuration as it is.
2) Configure an additional target-mode port.
3) Restore a target port to initiator mode.
3
Target: wwn.2100001b32050a28
Do you wish to restore this port to initiator mode? (y or n): y
Removing 'qlt' binding in /etc/driver_aliases
Are there additional ports you wish to reconfigure? (y or n): n
A reboot will be necessary for these changes to take effect.
Use the greplog utility to filter the acsss_event log to include or to exclude messages containing specific keywords. The syntax of this routine is similar to the UNIX 'grep' function. greplog is specifically designed for use with the acsss_event.log, but it may function with any type of message file where the records are separated by an empty line.
-v
Optional. The option displays all the messages in the log except those which include the keyword.
-i
Optional. This option ignores the case of characters in the specified keyword.
-keyword
returns the complete multi-line message containing the keyword.
-logfile
list of log files.
Since the utility is specifically designed for log files, greplog returns the complete multi-line message containing the keyword rather than a single line containing that word. Using the -i option, greplog ignores the case of characters in a specified keyword. Using the -v option, greplog displays all of the messages in the log except those which include the keyword. greplog is specifically designed for use with the acsss_event.log, but it may function with any type of message file where the records are separated by an empty line.
The install_scsi_Linux.sh utility creates /dev/mchanger* links which can be used when configuring libraries to ACSLS. Those mchanger names are now constructed using a serial number reported by the library, providing ACSLS with a reliable identifier that persists across changes in the SAN fabric or server reboots (both of which can change the underlying device paths for a library).
Information about the resulting /dev/mchanger links and the associated libraries is displayed as part of the script output, using the showDevs.sh utility. That utility can also be run as a stand-alone operation (after the mchanger links have been created) to display library information.
install_scsi_Linux.sh
Sample Output:
==========================================================================
# install/install_scsi_Linux.sh
[root@acslsdevx1 install]# ./install_scsi_Linux.sh
Installing SCSI device(s) for Oracle StorageTek ACSLS.
Adding ACSLS rules for udev ...
Starting udev: [ OK ]
Successfully built the following...
/dev/mchanger-3500104f00079f9d2: STK SL500 V-1485 336-cells 10-drives
/dev/mchanger-3500104f0007a8532: STK SL500 V-1485 205-cells 6-drives
/dev/mchanger-3500104f000cc6a67: STK SL150 V-0182 59-cells 4-drives
Installation of SCSI device(s) successfully completed.
#
===========================================================================
# utils/showDevs.sh
/dev/mchanger-3500104f00079f9d2: STK SL500 V-1485 336-cells 10-drives
/dev/mchanger-3500104f0007a8532: STK SL500 V-1485 205-cells 6-drives
/dev/mchanger-3500104f000cc6a67: STK SL150 V-0182 59-cells 4-drive
#
============================================================================
This routine returns the LSM type of the LSMs attached to the specified ACS ID. If multiple LSMs of a common type exist in the configuration, then only a single type is returned for the multiple LSMs.
The moving.sh utility moves multiple cartridges to one or more LSMs. This utility reads a file that lists the cartridges to be moved. These cartridges can be:
Cartridges in one or more LSMs
Cartridges on a panel being moved to other panels in the same LSM or other LSMs
Any group of cartridges you select
The limitations of moving.sh are:
All destination LSMs and cartridges in the vol_list_file must be in same ACS
If any destination LSM is offline or does not contain any free cells, no cartridges are moved to that LSM
Notes:
The moving.sh utility runs only if ACSLS is running
Internally, moving.sh moves only one cartridge at a time to avoid impacting library performance (mounts and dismounts)
You can run multiple move utilities in parallel after creating separate lists of volumes. Ensure that:
the destination LSM is same. Make sure that there are enough free cells in the LSM to accommodate all cartridges
you are moving within one SL8500 library - there are only two elevators, so running more than two move utilities at a time will not increase performance
moving.sh -f vol_list_file -t lsm_id or list of lsm_ids
Where:
-f vol_list_file
The name of the file containing the list of volumes to be moved.
Note:
The volume IDs must follow these rules: One cartridge-id per line; The vol_ids must be valid ACSLS volume IDs; If the vol_ids include trailing or leading spaces, they must be enclosed within single quotes or double quotes.-t lsm_id s
Specifies one or more LSM IDs to which the cartridges are moved. Each LSM ID should be separated by a space and belong to the same ACS.
Use the moving.sh utility to move a list of cartridges to other LSMs or from one panel to other panels in the same LSM.
You can use either a custom volume report or the display volume command to create a file containing the list of volumes to be moved from an LSM.
You want to use the moving.sh utility:
When a SL8500 is initially partitioned or re-partitioned, and one or more rails (LSMs) are removed from an existing partition (ACS), moving.sh can move cartridges from the LSM being removed from the partition to the LSM(s) that remains in the partition.
When any LSM(s) is removed from an ACS, moving.sh can move cartridges to the LSMs that remain in the ACS.
For example, if SL8500s are removed from a library complex (ACS), moving.sh moves cartridges from the SL8500s that are being removed to the LSMs that will remain in the library.
When a storage expansion module(s) is removed from an SL8500, cartridges can be moved from the panels being removed to the panels that remain in the library.
To optimize library performance, move inactive cartridges to an LSM with few or no drives that are used to archive cartridges. This frees up space in LSMs with drives for new, active cartridges.
Before you begin, you must create a file that contains the list of volumes to be moved from an LSM. You can use either the volrpt (custom volume report) or the display volume command.
Create a vol_list_file
volrpt -d -f custom_volrpt_input -l lsm_id > vol_list_file
Where the custom_volrpt_input file is:
VOLUME_ID 6
Sample output:
$ volrpt -d -f my_custom -l 0,2 > my_file_list $ cat my_file_list ABC744 ABC748 ABC756 ACS151 EN0823 O00373
Using the display volume command to create the vol_list_file
Display the list of volumes.
Example:
display volume * -home acs,lsm,panel,*,* -f vol_id
This example selects all volumes on the panel identified by the -home parameter. Row and column are wild-carded. Only the vol_id is output.
Sample output:
ACSSA> display volume * -home 0,3,5,*,* -f vol_id 2007-02-12 15:31:45 Display Volume Vol_id PG0350 PG0353 PG0356 PG0358 PQ0616
Create and name your vol_list_file.
Cut and paste the list of volumes (created from the display command) into this file.
Edit the output.
The vol_list_file cannot contain any blank lines and leading spaces. Use to following vi command to eliminate them.
:%s/^[ ]*//g
If you do not do this, you get an error message as shown in the following example.
$ moving.sh -f my_file_list -t 0,2 Error in file my_file_list. Invalid entry ABC748 ABC756 ACS151 EN0823
This error message was generated because there was an extra space before volumes ABC748 and 756.
Procedures for Moving a Group of Cartridges
The following procedures describe how to:
move cartridges before removing an LSM from an ACS
move cartridges before changing or removing panels
Moving Cartridges Before Removing an LSM from an ACS
After a library is reconfigured or re-partitioned, and if an LSM is removed from an ACS, all cartridges in the LSM become inaccessible. Therefore, before the LSM is removed, all of its cartridges should be moved to LSM(s) that will remain in the ACS. Use the following procedure:
When a rail (LSM) is removed from a legacy partition in a partitioned SL8500.
When an LSM(s) is removed from an ACS. The ACS can include 9310s or an SL8500 library.
Plan your new configuration.
Organize the cartridges and drives for performance.
Empty an LSM shortly before you change the library configuration.
Determine how many cartridges you have in the LSMs that you are emptying, and how many free cells in the LSMs to which you are moving cartridges.
Use free_cells.sh -a to find out the number of cartridges in these LSMs (allocated cells) and free cells.
Schedule the move and re-configuration.
Schedule the move to minimize the impact on your system.
Moving the cartridges takes time, and reconfiguring a library or re-partitioning an SL8500 is disruptive.
Make sure there are enough free cells in the target LSM(s) for the cartridges being moved. If needed, eject cartridges to free up space.
Vary all of the drives in the LSM being removed offline.
This prevents the following:
Vary the LSM being emptied to diagnostic mode to restrict access to only the cmd_proc using the following command:
vary lsm lsm_id diagnostic
Example: vary lsm 0,1 diagnostic
Run a custom volrpt to output all of the cartridges in the LSM being emptied to a file, using the following command:
volrpt -f custom_volrpt_input -l from_lsm_id > move_vols_list
Where the custom-volrpt_input is:
VOLUME_ID 6
Example: volrpt -f volrpt_input -l 0,1 > move_vols_list
Refer to "Creating a Logging Volume Statistics Report" for more information.
Move the cartridges out of the LSM being emptied, using the following command:
moving.sh -f move_vols_list -t dest_lsm_id(s)
Check that the LSM is empty using volrpt since the cartridges may have been entered into the LSM or may have ”floated” into it.
volrpt -l from_lsm_id
If it is not empty, run the custom volrpt again to select the volumes that are now in the LSM. Then, run moving.sh again (steps 3 and 4).
Note:
Do not runmoving.sh again with the original list of volumes.Vary the LSM being emptied offline to prevent volumes from being moved to it.
vary lsm lsm_id offline
Note:
Remove the LSM from the partition and/or ACS.Reconfigure the ACS using either config acs acs_id or acsss_config.
Moving Cartridges Before Removing Cells from a Partition
Note:
The SL3000 can partition down to the drive and cell level, and an SL8500 can partition to the drive and cell array level with enhanced partitioning. If cells are reassigned from one partition to another, the cartridges in those cells will be orphaned, and will no longer be accessible by the partition that they were in before. The host managing the other partition could write over the data on the cartridges.To prevent cartridges from being orphaned when partition boundaries change: before re-partitioning the library move them to cells that will remain in the partition. Since SL3000 is a single LSM, the existing ACSLS move command does not work. You would just move them somewhere else in the library. You might also move them to another cell that will also be removed from the partition.
Use one of the following methods to move your cartridges:
Use the StorageTek Library Console (SL Console).
Audit the library to audit your volume's locations.
Refer to the SL8500 or SL3000 User's Guide for detailed information and procedures.
Use the following ACSLS procedure:
Use "volrpt" or "Using display Command Options" to display volume locations.
Display a list of available (empty) cells in a specific panel using the following display command:
display cell a,l,p,*,* -status empty -f status
For more information, refer to "Using display Command Options".
Move the cartridges to a specific cell by specifying a free cell instead of an LSM ID. For a cell move, use the move command:
move AAAAAA a,l,p,r,c
Moving Cartridges Before Changing or Removing Panels
You must move the cartridges before changing a cell panel to a drive panel in a 9310 or removing a storage expansion module in an SL8500.
Steps 1 - 4 as procedures as "Moving Cartridges Before Removing an LSM from an ACS".
Step 5: Select the cartridges in the panel being emptied, and output them to a file.
Run a custom volrpt to output all of the cartridges in the LSM being emptied to a file. Include the panel number (in the home cell ID).
volrpt -f custom_volrpt_input -l from_lsm_id > move_vols_list_1
Where the custom-volrpt_input is:
VOLUME_ID 6 CELL_ID 14
Select the volumes in the panel(s) being emptied and output these vol_ids to your move_vols_list_2.
Select the cartridges in a panel being emptied using the display volume command.
display volume * -home acs,lsm,panel,*,* -f volume > move_vols_list_2
This selects all volumes on the panel identified by the -home parameter. The row and column are wild-carded. Only the vol_id is output, and the output writes to the file.
Edit the output, removing any leading spaces and the trailing blank line.
Note:
If the destination or ”to” LSM is the same as the source or ”from” LSM and more than one panel is being emptied, some volumes are moved back to the panels being emptied. You will have to select the volumes off the panels and move them repeatedly to clear out the panels.Steps 6 - 9 same procedures as "Moving Cartridges Before Removing an LSM from an ACS".
Step 10. Reconfigure the LSM, using either config lsm lsm_id or acsss_config.
Moving cartridges from LSM 0,4 to LSM 0,0 and 0,1
To move cartridges from LSM 0,4 to LSM 0,0 and 0,1, create a file containing the list of cartridges in LSM 0,4 using volrpt, and then run the moving.sh utility as below:
Sample output:
$ moving.sh -f vol_list.txt -t 0,0 0,1 Number of free cells in LSM 0,0 : 308 Number of free cells in LSM 0,1 : 362 ----------------------------------------- Total number of free cells : 670 Total number of volumes to move : 7 Cartridge CAB001 moved to 0,0,3,0,0 Cartridge CAB002 moved to 0,0,4,0,0 Cartridge CAB003 moved to 0,0,5,0,0 Cartridge CAB004 moved to 0,0,6,0,0 Cartridge CAB005 moved to 0,0,7,0,0 Cartridge CAB006 moved to 0,0,8,0,0 Cartridge CAB007 moved to 0,0,9,0,0 Summary ======= Number of free cells remaining in LSM 0,0 : 301 Number of free cells remaining in LSM 0,1 : 362 ------------------------------------------------ Total number of free cells remaining : 663 Number of cartridges moved : 7 Number of cartridges not moved : 0
Moving cartridges from LSMs 0,4 0,5 0,6 and 0,7 to LSMs 0,0 0,1 0,2 and 0,3,
To optimize performance by moving each LSM to the adjacent LSM:
Prepare files containing the list of cartridges in LSM 0,4 0,5 0,6 and 0,7 using volrpt.
Run four moving.sh utilities at the same time but in separate UNIX command terminals.
There is no contention between the separate instances of moving.sh because the source and destination LSMs and the pass-thru ports used are all different:
Sample Output:
moving.sh -f vol_list_0-4.txt -t 0,0 moving.sh -f vol_list_0-5.txt -t 0,1 moving.sh -f vol_list_0-6.txt -t 0,2 moving.sh -f vol_list_0-7.txt -t 0,3
Managing Cartridges for Performance
The moving.sh utility can be used to move inactive cartridges to archival LSMs. An archival LSM is an LSM with few or no drives that stores cartridges that have a low probability of being mounted. The top rail in an SL8500 is a good choice for an archival LSM because it does not have direct access to the CAP.
Inactive cartridges that do not need to be in a library can be ejected, while inactive cartridges that still need to be available for automated mounts should be moved to archival LSMs.
To move inactive cartridges to an archival LSM, complete the following procedure:
Identify the inactive cartridges. For example, to select cartridges that have not been accessed in the last three months:
Run a custom volrpt to output all of the cartridges in the LSM being examined, and output the results to a file.
volrpt -f custom_volrpt_input -l from_lsm_id > move_vols_list_1
Where the custom-volrpt_input is:
VOLUME_ID 6
ACCESS_DATE 15
Select the cartridges where the access_date is earlier than three months ago and output these vol_ids to a file with the list of volumes to be moved.
Move the inactive cartridges to the archival LSM.
moving.sh move_vols_list_2 archival_lsm_id
This utility displays all direct-attached or SAN-attached libraries behind a contemporary fibre-channel HBA.
The probeFibre.sh utility displays the model number, LUN ID and World Wide Port Name (WWPN) of each fibre-attached library. The probeFibre.sh utility can be run even before the mchanger devices are created for each library.
This utility requires root access.
No argument.
displays vendor, model, LUN ID and WWPN for each library device.
-v
produces a structured output that includes the model number of the host bus adapter (HBA) and the WWPN of each initiator port, along with the library devices detected on each port (including WWNN).
-p
produces an output that includes vendor:model:version:driver:target:lun:wwpn with each field delimited by a colon.
The rdb.acsss utility restores the ACSLS database and the ACSLS Control files using a backup created by either the automatic backup function or the bdb.acsss utility. The ACSLS Control files are located in $ACS_HOME/data, and define several different environmental variables for ACSLS. They specify Access Control settings, scratch preferences, Extended Store LSMs, custom volrpt settings, and volume attributes (for watch_vols utility), and so forth.
If you are restoring from a tape backup, be sure to rewind or position the tape device before restoring the ACSLS database and control files from tape. Use one of the following commands to rewind or position the tape to the exact location where the backup files resided before running rdb.acsss.
mt -f /dev/rmt/0mn rewind mt -f /dev/rmt/0mn nbsf 1
When you run rdb.acsss, a menu displays four options, as shown in the example below.
Please enter the number followed by Return for your choice from the following menu. Press? followed by the Return key for help. 1: Restore from a list of current local disk backup files 2: Restore from a previous tape or file backup 3: Restore database only (do not include ACSLS control files) 4: Restore only ACSLS non-database control files E: Exit
Restore from a current local disk backup
All of the current ACSLS backup files on the local disk are listed.
Explanation: The database is restored to the backup. ACSLS Control files are restored from the backup only. The backups are saved in the default backup directory ($ACSDB_BKUP). The database is restored to any database backup listed and selected. Usually there are 8 different dates listed, but this varies depending on the database retention period set in acsss_config.
Usage: Use this option to restore a corrupted database. With this option, all backups are displayed and you can restore to any displayed database backup.
Example:
Menu choice: 1 rcvr_previous.sh 2642: ACSLS database recovery started. You have taken backups on the following days. Please enter the corresponding date and time to the backup that you wish to recover from. ACSLS database and control files will be restored to that time. 2011-10-02 04:38:48 2011-10-03 00:00:01 2011-10-04 00:00:01 2011-10-05 00:00:01 2011-10-05 11:49:06 Please enter the recovery date and time (YYYY-MM-DD HH:MM:SS): HINT: You may copy and paste to enter the date and time.
You must enter the desired date and time from the relevant backup and the database is restored to that point.
Restore from previous tape or file backup
Explanation: Select this option to recover a database that was copied to a different file system (such as NFS) or to a backup device (such as tape). ACSLS Control files are restored.
Usage: Use for a catastrophic event such as hardware failure when the database must be restored to either the server or even an entirely different server. The platform (OS version/update and ACSLS release/PUT level) must be the same.
Option 2: Menu choice: 2. rcvr_manual.sh 2635: ACSLS recovery started To recover the ACSLS environment either: - Mount a ACSLS backup tape in a tape device and specify this tape device with '-f tape_device', or - Specify a file name containing a ACSLS backup with '-f backup_file'.
The ACSLS database will be recovered from the file specified.
Please enter -f [ backup_file | tape_device ]:
Example 1: Specifying a file with -f backup_file
Please mount tape (if used) and enter backup source: -f /export/backup/my_backup.bak
This would restore a backup called my_backup.bak. Both database and ACSLS Control files would be restored and ACSLS would be put back in the state that it was when the backup was run.
Example 2: Restoring a backup created on a tape device
Restoring a backup created on a tape device uses the same option but works a little differently. When a backup is created to a tape device, the tar archive is created on the tape but it does not have a name. When restoring a backup from a tape, only the tape device is given.
HINT: You should use a no rewind tape device.
Please mount tape (if used) and enter backup source: -f /dev/rmt/0mn
This goes to the device /dev/rmt/0mn and verifies that there is a valid database backup. If it does exist and is valid, it is restored.
Procedure to Rewind a Tape:
The tape must be REWOUND or POSITIONED at the correct location where the backup files reside before rdb.acsss is attempted.
Note:
After runningtar tvbf command, the tape is advanced to the next block. Make sure you have rewound/repositioned the tape if you intend to run rdb.acsss after running the tar tvbf command.The tape can be rewound/positioned using the following command:
mt -f /dev/rmt/0mn rewind or mt -f /dev/rmt/0mn nbsf 1 ---> SOLARIS
To verify the contents of tape after bdb.acsss, use the following commands:
tar tvbf 2048 /dev/rmt/0mn ---> SOLARIS
Restore database only (do not include ACSLS control files)
Explanation: The option provides to ability to restore data only. In some environments, you may need to restore the ACSLS database including its data, but you do not need to restore the ACSLS non-database control files.
Option 3: Menu choice: 3 To recover the ACSLS database data only, either: - Mount an ACSLS backup tape in a tape device and specify this tape device with '-f tape_device', or - Specify a file name containing an ACSLS backup with '-f backup_file'. The ACSLS database data will be recovered from the file specified. ****This option does not include the ACSLS control files**** Please enter -f [ backup_file | tape_device ]:
Restore only ACSLS non-database control files
Explanation: Restores only the ACSLS control files. Before restoring any file located in the $ACS_HOME/data/internal directory, backups are made of the existing files, appending the end with a ”.bak” extension.
$ACS_HOME/data/internal/dynamic_variables/dv_config.dat.bak $ACS_HOME/data/internal/dynamic_variables/dv_trace.dat $ACS_HOME/data/internal/release.vars.bak
This is not the case for files located in $ACS_HOME/data/external. No backups are performed of the ACSLS control files before recovery.
Option 4: Menu choice: 4 To recover the ACSLS non-database control files either: - Mount an ACSLS backup tape in a tape device and specify this tape device with '-f tape_device', or - Specify a file name containing an ACSLS backup with '-f backup_file'. ACSLS non-database control files will be recovered from the file specified. Please enter -f [ backup_file | tape_device ]:
Example:
Please enter -f [ backup_file | tape_device ]: -f $ACSDB_BKUP/my_file.bak
-f $ACSDB_BKUP/my_file.bak recovers the ACSLS control files from the specified file
-f /dev/rmt/0mn recovers ACSLS control files from the specified tape device
Exit
When you exit the rdb.acsss utility, a backup in initiated to the default directory, $ACSDB_BKUP.
The showDevs.sh utility displays the critical device attributes associated with each mchanger instance in the /dev directory. Critical attributes include the library model number and revision level, cell capacity and number of attached drives. Additional attributes can be displayed using the options below.
This utility can be run with several options.
No argument.
This option displays each mchanger, library model and code level, and number of cells and drives.
-w
World Wide Name - along with the basic information, displays WWPN of the attached libraries.
-s
Serial number - along with the basic information, displays library serial number.
Note:
To display server-side HBA information (including WWPN of HBA ports) and the WWPN of all attached libraries, use theprobeFibre.sh utility as user root.This utility presents a list of all configured drives attached to ACSLS. The simple list of drive locations is sorted by drive type. If the verbose (-v) option is used, the utility displays a summary showing drive state, drive status, and assigned logical status of each drive.
The stats_report utility generates library volume statistics reports. To run this utility, you must be logged in as acsss.
stats_report [vol_statsX.log ...]
Where:
vol_statsX.log -
.Using this optional argument, you can specify one or more archived Volume Statistics Log file names.
(The archived files have the format vol_statsX.log (where 0 <= X <= 8 ).)
Using one archived file as input:
$stats_report vol_stats0.log
The time centric and drive centric reports are generated with the name of the user input file pended to (and shown before) the report file name.
For example, if you specify vol_stats0.log then the reports will be generated in the $ACS_HOME/log directory as the following:
vol_stats0_drive_centric.txt and vol_stats0_time_centric.txt
To generate a report for all of the archived volume statistic files at once, follow the procedure below:
Generate the full log from individual files
$cd $ACS_HOME/log
$cat vol_stats8.log .... vol_stats0.log
acsss_stats.log > vol_statsXXXX.log
where vol_statsXXXX.log
(The string vol_stats is necessary, but XXXX can be anything like FULL, and so on) is the concatenated file of all vol_statsX.log(where 0 <= X <= 8) and acsss_stats.log in reverse order.
Run stats_report
$stats_report vol_statsXXXX.log
Reports are generated as vol_statsXXXX_drive_centric.txt and vol_statsXXXX_time_centric.txt.
If no filename is given as an argument, then the time centric and drive centric reports are generated from $ACS_HOME/log/acsss_stats.log.
The stats_report uses the current acsss_stats.log to prepare two reports of volume statistics. Enable library volume statistics gathering by setting the variable LIB_VOL_STATS. This can be done through the acsss_config (option 3) process or through the command line command dv_config -p LIB_VOL_STATS. ACSLS then automatically rolls and maintains 9 acsss_stats.log files when the log reaches the default size of 500 KB.
The size of the log files and the number of files to retain is controlled through the variables LIB_STATS_FILE_NUM and VOL_STATS_FILE_SIZE. These variables are set using the same method as LIB_VOL_STATS discussed above.
The two types of reports are:
drive_centric.txt
This report contains an ordered list of drives. Each drive record contains all cartridges mounted to the drive, the requestor, the time of the request and the duration of the mount.
time_centric.txt
Note:
This report contains the usage of drive resources listed on an hourly time scale. Each record in a time period includes the requestor, the specific drive, the number of mounts during that period for that drive, and the duration of drive usage during the hour.If the drive usage exceeds 60 minutes for a time period, it is an indication that the mount spanned two time periods and thus, will not be listed in the second time period.The first report created by stats_report is a drive view.
Notes:
If there is a DISMOUNT record in the log but there is no corresponding MOUNT record, the reason could be that:
The log was rolled over, or
The operation was logged due to some unknown logging problem.
In this case, the record is omitted from the report generated.
If there is a MOUNT record in the log but there is no corresponding DISMOUNT record, the reason could be that:
The DISMOUNT has not yet happened, or
The operation was not logged due to some unknown logging problem.
In this case, the mount duration is set to -1, which is an indication of cases mentioned above. These records are omitted from calculating the total mount duration in the time centric report.
In the cases of going from day light savings time to standard time, scenarios where the calculated mount duration is negative can arise. To suppress them, the absolute value of the mount duration is taken.
The userAdmin.sh menu-driven utility administers ACSLS GUI user passwords. It is found in the $ACS_HOME/install directory. You can add users, remove users, list users, and change user passwords. WebLogic must be running to use this utility. If it is not up, this utility starts WebLogic and confirms that it is online before displaying the menu.
This utility is run by root, and requires acsls_admin authentication. The acsls_admin user account is configured during ACSLS 8.5 installation.
When adding a user or changing a password for any user, you are prompted for the user name and assigning password. The password is verified against WebLogic criteria of size and legal characters.
When a user is removed, that account could still have an active GUI session. Once the user logs out or terminates the session, the user will be unable to log back in. Restarting the GUI is the only way to force the session to terminate immediately. An option is provided to restart the ACSLS GUI (which terminates all sessions).
You cannot use this utility to change the password for the acsls_admin user. When it is necessary to change or reset the password for acsls_admin, you should:
Run the wlinstall.sh utility.
$installDir/wlinstall/wlinstall.sh
Run userAdmin.sh to re-establish the remaining user accounts.
userAdmin.sh
# ./userAdmin.sh
ACSLS GUI User Administration
Weblogic is online.
Please enter the acsls_admin password:
Authenticating.........Connected!
Menu:
1) Add a user account.
2) Remove a user account.
3) Change a user password.
4) List users.
5) Restart ACSLS GUI.
6) Exit.
Please select by number: 1
--- Add a User ---
Please enter the id of the user you wish to add: acsss
Do you wish to add a GUI account for user 'acsss'? (y/n) y
Please assign a password for 'acsss'.
Passwd: Please confirm password:
Passwd:
Connecting..........
User accounts has been added.
Please select by number: 2
--- Remove a User ---
Please enter the name of the user you wish to remove: accounts
Do you wish to remove the ACSLS GUI account for user 'accounts'? (y/n) y
Connecting..........
The account for accounts has been removed for future logins.>
To disable any current login session for accounts, you
must restart the ACSLS GUI.
Please select by number: 3
--- Change Password ---
Enter the user name: acsss
Passwd: Please confirm password:
Passwd:
Connecting..........
Password changed for acsss!
Please select by number: 4
--- List Users ---
Connecting..........
Configured WebLogic users:
OracleSystemUser
acsls_admin
acsss
Please select by number: 5
Do you wish to restart the ACSLS GUI (affects all users)? (y/n) y
Restarting:
Disabling WebLogic ...........................
Enabling WebLogic ................................
Please select by number: e
#
The volrpt utility creates a volume report.
-s
specifies the sort order. If you do not specify this option, the default is to sort by volume ID. If you specify this option, you must specify one of the following values:
vol
sort by volume ID.
loc
sort by volume home location.
use
sort by volume use (number of mounts).
-d
specifies that the output contains no page breaks or header information. The output can be used as input to other programs such as pr.
-f filename
filename specifies a custom volrpt template.
-z
zero fills identifier fields.
-a
restricts the report to the specified ACS. You can specify multiple ACSs (use blanks to separate the acs_ids).
-l
restricts the report to the specified LSM. You can specify multiple LSMs (use blanks to separate the lsm_ids).
-v
restricts the report to the specified volumes (or volume ranges). You can specify a single vol_id, a list of vol_ids separated by blanks, or a volume range indicated by vol_id-vol_id.
identifier_list
described by the -v, -a, and -l options. This is a list of ACSs, LSMs, and volumes (or volume ranges).
-i
reports all volumes, including absent and ejected cartridges.
If this option is not specified, absent and ejected cartridges are not reported.
Use the volrpt utility to create a report of library cartridges, including their physical location, history, attributes, and use. You can also use volrpt to verify the database after you restore it. You can use the -a, -l, or -v options to specify the ACSs, LSMs, or cartridges for the report. If you do not specify any of these options, volrpt reports on only ACS 0.
Note:
Special consideration for leading and trailing spaces. When specifying arguments for volumes that contain leading or trailing spaces, you should enclose the arguments in single quotes. To assure that the single quote will be passed from one shell component to another, the quote must be tagged with an escape character. In UNIX, the standard escape character is the backslash (\).
Examples:
To formulate a volrpt command on the local machine where you want to reference volume id's with a leading space, you would submit the command, as follows:
volrpt -v \'0000\'-\'9999\'
To submit the same command through a remote shell (rsh) you would enclose the entire argument inside double quotes:
rsh <acsls_hostname> -l acsss bin/volrpt -v "\' 0000\'-\' 9999\'"
The following example shows a standard volume report, which contains fields for volume id, location, label type, media type, and history of usage.
VOLUME REPORT UTILITY 2002-06-30 14:01:21 TOTAL VOLUMES: 400 SEQUENCE: sort by volume identifier Volume Home LabelVolume Times|---Entered---||--Last Used--| Label Location AttrType/Media MountedDateTime DateTime CLN000 0,0,1,0,3 ExtC/STK1U 108/22/0109:30 10/04/01 14:26 RB0000 0,1,2,1,10Ext.D/STK1R 310/01/0108:16 10/01/01 08:18 RB1400 0,0,10,1,3Ext.S/STK1R 24310/01/0109:30 10/06/01 11:04 RB1401 0,0,10,3,5Virt.D/STK1R 1210/01/0103:29 10/05/01 23:11 ” " " " " "" " " " " " "" " " " " " "" TB1440 0,1,3,1,9 Ext.D/STK2P 4308/12/0109:1109/28/0117:52 " " " " " "" " " " " " "" " " " " " ""
In the Volume Type/Media column: C denotes cleaning cartridges; D denotes data cartridges; P denotes a cleaning cartridge that was reported as spent (used-up) by a tape drive; and S denotes scratch cartridges.
Use the -f filename option to create a customized report; see "Creating a Logging Volume Statistics Report", for more information.
$ACS_HOME/data/external/volrpt/owner_id.volrpt is a sample input file that you can run or use as a template to create customized volume reports. You can also save your customized volume reports in the $ACS_HOME/data/external/volrpt directory.
You can redirect the volume report to a file with standard UNIX redirection:
volrpt > file
By default, volrpt reports only the first ACS in the list. To report the cartridges in both ACS 0 and ACS 1, enter the following command:
volrpt -a 0 1
To report the cartridges in LSMs 0,1 and 2,1 sorted by home cell location, enter the following command:
volrpt -s loc -l 0,1 2,1
Notes:
volrpt displays the specified volume report if it completes successfully. volrpt prints a message to stderr and exits if you specify the -f option and volrpt cannot find the specified file or you specify more than one input file. For field errors within the input file, volrpt prints a message to stderr and ignores the line in error but does not exit.
If cartridges are not found in the volume ID list, range or library component specified, volrpt returns a no volumes found message.
When a parameter is not specified, it uses the default of ACS 0.
If a library component(s) is specified through the -a, -l, or -v option, but no volumes are found, messages such as the following are displayed:
-a option (ACS)
Messages:
when a single acs_id is provided and no volumes are present, the following error displays: No Volumes found for ACS: (<acsid>)
Example:
$ volrpt -a 2 No Volumes found for ACS: (2)
when multiple acs_ids are provided and none of them have any volumes, the following error displays:
No Volumes found for ACS: (<acsid1>)(<acsid2>)
Example:
$ volrpt -a 0 1 No Volumes found for LSM: (0) (1)
-l option (LSM)
Messages:
when a single lsm_id is provided and no volumes are present, the following error displays: No Volumes found for LSM: (<lsmid>)
Example:
$ volrpt -l 1,1 No Volumes found for LSM: (1,1)
when multiple lsm_ids are provided and none of them have any volumes, the following error displays: No Volumes found for LSM: (<lsmid1>)(<lsmid2>)
Example:
$ volrpt -l 1,1 1,2 No Volumes found for LSM: (1,1) (1,2)
-v option (VOLUME)
Messages:
when a single volid is provided and no volumes are present, the following error displays: Volume(s) not: (<volid>)
Example:
$ volrpt -v BBB112 No Volumes found: (BBB112)
when multiple volids are provided and none of them have any volumes, the following error displays: Volume(s) not found: (<volid1>)(<volid2>)
Example:
$ volrpt -v BBB112 BBB114 No Volumes found: (BBB112) (BBB114)
The -v option can also be used for volume range, and produces similar messages when no volumes are present.
when a single volume range is provided and no volumes are present, the following error displays: Volume(s) not: (<volrange>).
Example:
$ volrpt -v BBB112-BBB116 No Volumes found: (BBB112-BBB116)
when multiple volume range is provided and no volumes are present, the following error displays: Volume(s) not: (<volrange1>) (<volrange2>)
Example:
$ volrpt -v BBB112-BBB116 BBB220-BBB224 No Volumes found: (BBB112-BBB116) (BBB220-BBB224)
When an ACS or LSM has not been configured
When volrpt is used with an acs_id or lsm_id that does not exist, it displays a message according to the identifier.
-a (ACS)
ACS identifier (<acsid>) not configured
-l (LSM)
LSM identifier (<lsmid>) not configured
This utility applies pre-defined policies for volumes that are:
newly entered
discovered by audit or cartridge recovery
re-activated by audit, cartridge recovery, or an enter
These policies are defined in the file:
$ACS_HOME/data/external/vol_attr.dat
This file contains a list of user-defined volume IDs or volume ranges and a user-specified policy for each volume recorded. For each volume or volume range listed in that file, you can define volume ownership, pool association, preferred LSM location, and/or logical library assignment when a volume is entered. Specific instructions for defining policies are explained in detail in the vol_attr.dat file.
The watch_vols utility uses the acsss_stats.log to identify the existence of newly entered volumes or volumes discovered or re-activated during an audit or by cartridge recovery. To enable this capability, you must enable volume statistics with acsss_config (option 3). With volume statistics enabled, watch_vols monitors the tail of the acsss_stats.log, looking for matching volumes with the entries defined in vol_attr.dat. Wherever a match is found, the defined policy for that volume is automatically applied.
The volume IDs must follow these rules:
One vol_id or volume range per line.
The vol_ids must be valid ACSLS volume IDs.
If the vol_ids include trailing or leading spaces, they must be represented as underscores (_). For example: _V234_.
You can check the running status of the utility by invoking watch_vols with no parameter. If you are unsure of the status of watch_vols (running or stopped), the command watch_vols with no argument displays the current status.
There are two options for watch_vols, start and stop.
watch_vols start
When the start parameter is invoked, watch_vols reviews the policies defined in vol_attr.dat. If there are errors in format or syntax, watch_vols displays the error and prompts you to make the necessary correction to vol_attr.dat. Once the defined policy is accepted by watch_vols, the utility invokes a daemon to run in the background. The daemon continues to run if ACSLS is running. It starts automatically whenever ACSLS is restarted.
The policy table in vol_attr.dat can be updated at any time. You need not stop watch_vols in order to update the policy. Just run watch_vols start to commit the updates to the running program.
watch_vols stop
This command stops any further policy enforcement for the specified volumes.
A log of all watch_vols activities is maintained in the log file:
$ACS_HOME/log/watch_vols_event.log
Each change of volume ownership, pool_id, or LSM home location is logged in this file.
You are performing an enter operation and you want to move specific volumes to a target LSM when they are entered.
Audit the target LSM with watch_vols disabled.
Once the target LSM has been audited, start watch_vols.
Enter the volumes that have policies defined in vol_attr.dat.
watch_vols then moves the specified volumes to the destination LSM after they are entered.