ACSLS Support for Library Upgrade of SL3000 to SL4000

A field upgrade option is available to convert an SL3000 library into an SL4000 library. Although only ACSLS 8.5 can support the SL4000, either ACSLS 8.4 or ACSLS 8.5 may be managing the SL3000.

If ACSLS 8.4 (or a patch to 8.4) is currently managing the SL3000, use either of the following options:

  • You can perform the library upgrade during the upgrade from ACSLS 8.4.0 to 8.5.0.

  • You can perform the library upgrade after first importing the SL3000 into ACSLS 8.5.0

With either option, you remove the SL3000 library from the current configuration (by running acsss_config), and then add the SL4000 library to the ACSLS 8.5.0 configuration. After the library upgrade is complete, use either acsss_config or config acs new to add the SL4000 library. Once you run an audit against the SL4000, the library is ready for operation.

  • If you plan to bring an upgraded SL4000 directly into ACSLS 8.5, remove the SL3000 library from the ACSLS 8.4 configuration before exporting the database for the upgrade to the 8.5 release. The library upgrade can be performed at the same time as the ACSLS upgrade.

  • If ACSLS 8.5 is already managing the SL3000 prior to the library upgrade, shut down ACSLS and run acsss_config to drop the SL3000. The library upgrade can be performed at that time. No database export or import is needed.

Important Considerations

  • Drives and media supported by the SL4000 are not the same as those supported in the SL3000. Any affected drives or media should be physically removed from the SL3000 as part of the library upgrade.

  • Once the library is ready and operational, perform all required library setup to create a user and password, certificates, etc. You will need this authentication information to configure the library to ACSLS.

  • You must always run an ACSLS audit against a new library before starting client operations.

What About my Volume Information?

By default, ACSLS retains volume records for 5 days after a volume is ejected or is marked absent (no longer in the library). This allows us to preserve information such as use count, last access date, or ownership.

Be sure to retain absent/ejected volumes for some non-zero period (dv_config -p ABSENT_VOLUME_RETENTION_PERIOD). A value of zero indicates to delete those records immediately.

After the SL3000 library is removed, the volumes are considered absent. When audit is run against the SL4000, the volume records are re-activated with new home locations.

What About my Logical Libraries?

There is no provision for exporting a logical configuration, and the physical drive identifiers associated with any logical library backed by the SL3000 will change (panel numbers will be different). Therefore, the logical configuration must be re-defined after the SL4000 has been added to the ACSLS 8.5 physical configuration.

You can use the lib_cmd display command to create a record of the existing logical configuration (libraries, drives, volumes and mappings) for reference.

What About my Client Applications?

Because the drive identifiers will change between the SL3000 and SL4000, along with CAP identifiers, client applications may need to refresh their view of the library configuration and then re-inventory the library. This is especially true for ACSAPI clients, which use ACSLS drive identifiers directly. However, even FC (logical) clients must refresh their views, since the element addresses for their resources may have changed.There should be no impact to XAPI clients, as library configuration is re-discovered at startup.

Using watch_vol

You can use the watch_vol utility, along with the vol_attr.dat file, to automatically assign various attributes when a volume is entered, discovered, or re-activated. This may be helpful in automating some of the media management tasks, including assignment of volume owner, logical library, etc.