Yes, I saw something like this a week or two ago. On a Friday night all
the client schedules started to fail, giving errors like "Schedule lock
problem", etc. and some other weird stuff I've never seen before.
Because it happenned on a Friday, none of the weekend schedules, client
or admin occurred.
Also, upon noticing this, I bounced the dsmserv process and everything
went back to normal.
In our case, however, we had several unusual log entries like I
mentioned above. More specifically, they looked like this:
11/02/01 20:31:33 ANR9999D csutil.c(409): ThreadId<65> Lock
acquisition
(sLock) failed for CS universe
11/02/01 20:31:33 ANR2705E cscmdsch.c(315) Scheduler lock failed:
-1.
11/02/01 20:31:33 ANR2573W Sufficient memory is not available for
11/02/01 20:31:33 ANR2573W Sufficient memory is not available for
the
central scheduler - will retry in 60 seconds.
11/02/01 20:32:33 ANR0486W Session 5620 for node NODE1 (WinNT)
terminated - internal error detected.
11/02/01 20:51:28 ANR9999D lmutil.c(1750): ThreadId<82> Lock
acquisition
(xLock) failed for License Details
11/02/01 20:51:28 ANR9999D lmutil.c(811): ThreadId<82> Lock
conflict
encountered in License Manager.
11/03/01 04:02:50 ANR2571W Scheduled session from node NODE2
(WinNT) has been denied, scheduled sessions
are not
currently available.
Also, there was NO shortage of memory and our licenses are in
compliance. So, I have no idea where those errors came from.
I have opened up a case with Tivoli Support. Other than that, I can't
think of anything to do.
adam
"Prather, Wanda" wrote:
> We'll the TSM server is nothing if not creative. We are TSM 4.1.3 on AIX
> 4.3.3.
>
> Night before last, during the DB BACKUP, the TSM server inexplicably
> starting issuing the message:
>
> ANR2571W Scheduled session from node xxxxxxxx has
> been denied, scheduled sessions are not currently available.
>
> And it kept doing that for hours. When we came in the next morning, Q
> SESSION showed NO client sessions at all, 3 admin sessions running (all of
> them us confused admins trying to figure out what's going on...), still
> issing ANR2571 any time a client tried to connect.
>
> We killed the only process running, which was a BACKUP STGPOOL. And that
> left TSM sitting in spendid isolation twiddling its thumbs, still refusing
> sessions.
>
> Bouncing the server fixed it. NOTHING WHATEVER in the TSM log to indicate
> other problems.
>
> Anybody seen this one before?
|