ADSM-L

Re: ANR9999 message Lock acquisition - TSM 4.2.1.15 server

2002-08-14 19:05:56
Subject: Re: ANR9999 message Lock acquisition - TSM 4.2.1.15 server
From: Shannon Bach <SBach AT MGE DOT COM>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Wed, 14 Aug 2002 18:05:54 -0500
Brian,
     We run with OS/390  2.8 and TSM Server Version 4.2.2..  I was getting
the same messages with 4.2.1 as you are and no longer get that message with
upgrade.  We only have one problem message with 4.2.2 but there is a fix
for it.  When it's a PTF we will put it in.  It is;   ANR9999D
ASALLOC(663): ThreadId<5155> Volume 1XXXXX being accessed remotely - ending
repair attempt when the server real busy.  It hasn't caused any harm, PTR
say it is harmless.  I do an audit on the volume fix=yes just in case when
it does happen.



Shannon Bach
Madison Gas & Electric Co.
Operations Analyst - Data Center Services
Office 608-252-7260
Fax 608-252-7098
e-mail sbach AT mge DOT com



                      "Brian L. Nick"
                      <BRIAN.NICK@PHOEN        To:       ADSM-L AT VM.MARIST 
DOT EDU
                      IXWM.COM>                cc:
                      Sent by: "ADSM:          Subject:  ANR9999 message Lock 
acquisition - TSM 4.2.1.15
                      Dist Stor                 server
                      Manager"
                      <[email protected]
                      .EDU>


                      08/14/2002 09:15
                      AM
                      Please respond to
                      "ADSM: Dist Stor
                      Manager"






Good morning,

 We are running TSM 4.2.1.15 on OS/390 2.10 and are having several issues.
One of these is poor performance since upgrading from 4.2.2.0 to 4.2.1.15.
Also we are receiving the following error message after issuing an update
storage pool command:


ANR9999D SSUTIL(943): ThreadId<15401> Lock acquisition (ixLock) failed for
SS
universe lock.
ANR2753I (DAILY_APL_MIGRATION_AVOID):ANR2033E UPDATE STGPOOL:
ANR2753I (DAILY_APL_MIGRATION_AVOID):Command failed - lock conflict.

 This condition seems to occur when we are in a heavy backup period, which
since upgrading to 4.2.1.15 is very often. I need to test 4.2.2.0 before
upgrading to that release, we applied the 4.2.1.15 fix level at the
recommendation of Tivoli even thought 4.2.2.0 was available.  Is anyone
running 4.2.2.0 on OS/390 2.10 and if so have you run into any gotcha's?

 Thanks for  any input.

 - Brian



Brian L. Nick
Systems Technician - Storage Solutions
The Phoenix Companies Inc.
100 Bright Meadow Blvd
Enfield CT. 06082-1900

E-MAIL:  Brian.Nick AT phoenixwm DOT com
PHONE:   (860)403-2281