In its normal initialization sequence, TSM locks all of its library
resources under a common lock id.  On rare occasions, TSM has been known to
initialize resources with a second lockid after existing resources had been
locked under a different lockid.  In this situation, intervention will be
required to establish a common lockid for all resources.

The standard intervention procedure would be to use the ACSLS cmd_proc to
clear all of the locks on library resources.  First, get a list of lockids:

        ACSSA> query lock volume all
        ACSSA> query lock drive all

Look for the lockid associated with these resources.

Now, remove each lockid as follows:

        ACSSA> set lock <lockid>
        ACSSA> clear lock volume all
        ACSSA> clear lock drive all

Repeat this sequence for each unique lockid.  Once the locks on all
resources have been removed, you can restart TSM.   When TSM software
initializes, it will lock all of its library resources under a single
lockid.

There may be an occasion in which you cannot set your lockid to a known
lockid value.  The most likely cause for this condition would be that the
lockid record has been removed while resources had been locked under that
lockid.  A bug was introduced in ACSLS 6.0 (6.0.1) in which it is possible
to remove a lockid record of locked resources by attempting to lock a
non-existing resource under that lockid.  If this bug is encountered, it
will force TSM to lock subsequent resources under a new lockid.   A fix for
this ACSLS bug is available in PTF760827 (for Solaris) and PTF762430 (for
AIX).  The fix has been rolled into ACSLS 6.1.

One way to determine whether a lockid record had been removed is to query
the database directly.
First, determine the lockid of all locked resources:

        sql.sh "select lock_id from volumetable where lock_id<>0"
        sql.sh "select lock_id from drivetable where lock_id<>0"

Now, confirm that a lockid record exists for each lockid you established
above:

        sql.sh "select lock_id, user_id from lockidtable"

If you find that a lockid exists in the volumetable or the drivetable, but
that lockid does not exist in the lockidtable, then this is a sign that the
lockid record has been removed.  In this case, use the following procedure
to correct the situation:

        1.  Install PTFPTF760827 (for Solaris) or PTF762430 (for AIX).
        2.  Remove all lockids from the ACSLS volumetable and drivetable as
follows:

                sql.sh "update volumetable set lock_id=0 where lock_id<>0"
                sql.sh "update drivetable set lock_id=0 where lock_id<>0"

        3.  Drop the lockidtable as follows:

                sql.sh "drop table lockidtable"

        4. Rebuild the lockidtable, using acsss_config.

                kill.acsss
                acsss_config
                      select option 7 (exit)
                      This will create a new lockidtable
                rc.acsss

        5.  Restart TSM software to establish a new common lockid.
Terry

-----Original Message-----
From: Firmes, Stephen [mailto:Stephen.Firmes AT STORAGENETWORKS DOT COM]
Sent: September 09, 2002 10:02 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: ACSLS Lock error


When I start the TSM server the library does not get initialized due to the
following error:

09/09/2002 10:58:27  ANR8855E ACSAPI(acs_lock_volume) response with
                      unsuccessful status, status=STATUS_LOCK_FAILED.
09/09/2002 10:58:27  ANR8851E Initialization failed for ACSLS library
LIBRARY1
                      will retry in 2 minute(s).

I have recyled the TSM server and the ACSLS daemon,  the ACSLS app and
server, and I even rebooted both boxes.  Still no luck.

Any ideas?

TSM 5.1.1.1
Solaris 8
ACSLS 6.0.1

Thanks for any help.

Stephen Firmes
TSM Engineer
Tivoli Certified TSM Consultant
StorageNetworks, Inc
Work:  781-622-6287
http://www.storagenetworks.com