Performing Post Installation Tasks

Once ACSLS is installed, you can perform the following post-installation tasks:

Adjusting ACSLS Tuning Settings

Set recommended ACSLS tuning settings for your configuration. See "ACSLS Tuning Settings".

Installing the XAPI Service

The optional XML API (XAPI) service is an API that enables Enterprise level mainframe clients and servers to communicate using a common Enterprise Library Software (ELS) protocol over TCP/IP. ACSLS 8.5 and later releases can be configured with XAPI support.

To install the XAPI component:

Ensure you have installed the ACSLS package and run install.sh to finish the ACSLS installation.
Ensure you are logged in to the ACSLS server as root.
Source key ACSLS environment variables:
```
. /var/tmp/acsls/.acsls_env
```
(Note the required period and space before /var/tmp/acsls/.acsls_env).

Install the XAPI component:

cd $ACS_HOME/install
./install_xapi.sh
Installing the XAPI component for Oracle IBM mainframe clients. Continue? (y)

Importing Database and Control Files

Database and control files are customized files, user preferences, and local configuration files that are unique to your specific ACSLS environment.

If you exported existing database and control files before installing ACSLS 8.5, as described in "Step 1: Export Existing Database and Control Files", you can use the db_import.sh utility to import them once ACSLS 8.5 is installed.

Refer to the "Database Administration" chapter in the StorageTek ACSLS Administrator's Guide for this procedure.

Testing ACSLS Without a Library

After installing a new ACSLS release, you want to test it before using it to manage production libraries. If a test library environment is not available, this can be difficult because normally ACSLS must be configured to a library, and the library must be online for ACSLS to come up.

If you do not have a configured library or library partition available in a test environment, you can test a new ACSLS release in a limited way without having a test library for ACSLS to access. To do this:

Install the new ACSLS release on a separate server.
Export the database and control files from a production library environment using the db_export.sh utility. Refer to the StorageTek ACSLS Administrator's Guide for details.

Note:

ACSLS must be down to export the database and control files.
Import the database and control files into your new ACSLS release using db_import.sh.
On your new ACSLS system, ensure that ACSLS does not try to connect to the imported library configuration. The ACSs and ports must stay offline to ACSLS.
Otherwise, both the new ACSLS system and production system try to connect to the library, disconnecting the other system, and then in turn being disconnected by the other system. This repeats until one of the ACSLS systems is shut down.

To keep all ACSs and port connections offline:
- Modify the acsls_startup_policy file, in $ACS_HOME/data/external/.
- Uncomment the line for each ACS that is configured in the imported database. Look at the comment header of acsls_startup_policy for details.
  
  For example, to prevent ACSLS from trying to bring ACS 0 online, change:
  
  # ACS0_desired_startup_state_is_offline
  
  to
  
  ACS0_desired_startup_state_is_offline
Test to ensure that ACSLS comes up and runs, exercising a limited set of commands.
- Do not vary ports or ACSs online. If you do, you will halt library communication from your production ACSLS system.
- Commands that send requests to the library will fail because the library is offline. However, ACSLS will continue to run and process requests.
- Commands that do not rely on library resources work. These include submitting these commands using the ACSAPI from host applications:
  
  query
  
  display
  
  define pool and delete pool
  
  idle and start
  
  lock and unlock
  
  set commands, except for set cap mode which will fail because the library is offline.
- Utilities that do not rely on library resources work. These include:
  
  acsss commands such as acsss enable, acsss disable, acsss status.
  
  bdb.acsss and rdb.acsss
  
  db_export.sh and db_import.sh
  
  Note:
  
  db_import.sh overlays the acsls_startup_policy file. If this is a production system, this allows libraries to come online. Modify the acsls_startup_policy file before starting ACSLS.
  
  dv_config
  
  drives_media.sh
  
  free_cells.sh
  
  userAdmin.sh
  
  volrpt
  
  watch_vols
- The ACSLS GUI will display library resources. However, commands such as mount, dismount, enter, and eject which requires library resources will fail.

Verifying the ACSLS Installation

To verify the ACSLS installation:

Ensure that your library is configured.
Follow the instructions provided in the ACSLS Administrator's Guide to use acsss_config to configure ACSLS and create a database image of your library.
Note:

If you plan to use the SL4000 library, before running acsss_config, ensure that you have completed the following library configuration tasks using the SL4000 GUI:
- Define an SL4000 library certificate, including the Library Name (CN). This name must match that used in acsss_config and config new acs. If using a host name (DN), not an IP address, it must also resolve to the same exact name.
- Define an SL4000 user that the ACSLS SCI interface can use to connect to the SL4000 library.
  
  Note:
  ACSLS SCI connection to an SL4000 library requires an SL4000 user credential with a user role at the User level. The SL4000 Administrator role can also be used for this credential.
- Ensure that the SL4000 library is SCI capable, or has an SCI capable partition.
- Ensure ACSLS server time and SL4000 library time are synced within a couple minutes of each other.
Refer to the ACSLS Administrator's Guide for more information about these tasks.
Log in as user acsss.
Run the acsss enable command to start ACSLS.
Run cmd_proc.
From cmd_proc, query the server:
Verify that the following are online:
```
query port all
query acs all
query lsm all
query cap all
query drive all
```
At least one of each must be online. If necessary, use the vary command to bring them online.
Audit the library.

Refer to "Auditing the Library" in the StorageTek ACSLS Administrator's Guide.
Do you have at least one cartridge in an LSM?
- YES - Continue with the procedure.
- NO - Enter a cartridge into an LSM.
List available volume and drive IDs.
```
query vol all
query drive all
```
Mount a volume:
```
mount vol_id drive_id
```
where vol_id is the volume ID and drive_id is the drive ID.

Refer to the StorageTek ACSLS Administrator's Guide for more information.
Do you see a message indicating a successful mount?
A successful mount message is:
```
Mount: vol_id mounted on drive_id
```
- YES - Procedure is complete.
- NO - If an error message appears, run this verification procedure again, ensuring that you specified a valid, available drive and a library cartridge. If the mount continues to fail, contact Oracle Support for assistance.
Dismount the cartridge by entering:
```
dismount vol_id drive_id force
```
where vol_id is the volume and drive_id is the drive you mounted earlier in the procedure.
The verification procedure is complete.