ADSM-L

Re: ADSM 3.1.2.50 problems.

2000-01-13 08:54:49
Subject: Re: ADSM 3.1.2.50 problems.
From: Kirsten Gloeer <Kirsten.Gloeer AT RZ.UNI-KARLSRUHE DOT DE>
Date: Wed, 13 Jan 0100 14:54:49 +0100
Hi Sheelagh,

We have the same problem with canceling sessions. We have opened
it as PMR 73239. Some of these sessions are several weeks within
our server. The only possibility to cancel these sessions is to
restart the server.

We haven't seen the tape drive problems, either.

During the next week, we want to upgrade our first ADSM server 3.1.2.50
to TSM 3.7.1.

Best regards,
Kirsten Gloeer
------------------------------------------------------------------------
Kirsten Gloeer                  e-mail: gloeer AT rz.uni-karlsruhe DOT de
Kirsten Gloeer                  e-mail: gloeer AT rz.uni-karlsruhe DOT de
University of Karlsruhe         Phone:  +49 721 608-6156
Computing Center                Fax:    +49 721 32550
Zirkel 2
76131 Karlsruhe
Germany
------------------------------------------------------------------------
> Hi Mauro,
> Hi Mauro,
>
> I saw the same problem with sessions within hours of 3.1.2.50 and
> after 36 hours we had 5 festering sessions.  I reported it as PMR
> 83211 and then went back to 3.1.2.42 as we would soon run out of
> session slots at that rate!  I believe others have also reported
> this problem but as yet there is no fix available.
>
> Other problems at 3.1.2.50 that we have seen are the invalid replies
> from the current_timestamp and current_date (using select built-in
> funcions).  [APAR taken out for this is IY06877]
>
> Also the new functionality relating to session throughput gives
> worrying references to admin sessions when you do something like:
>
>   query sess maxthr=100
>
> and really it should be talking only about client sessions - as you
> wouldn't want to risk thinking of cancelling your admin sessions by
> mistake.  [APAR for this is IY06909].
>
> I haven't seen the tape drive problems - that needs reporting, it
> shouldn't do that?
>
> Anyone care to share how TSM 3.7.1 server is going on a large system?
>
> Anyone upgraded a large system yet from 3.1 to 3.7.1?
>
> Best regards, Sheelagh
> ------------------------------------------------------------------------
> Sheelagh Treweek                   Email: sheelagh.treweek AT oucs.ox.ac DOT 
> uk
> Oxford University Computing Services           Tel:   +44 (0)1865 273205
> 13 Banbury Road, Oxford, OX2 6NN, UK           Fax:   +44 (0)1865 273275
> ------------------------------------------------------------------------
>
> >X-OpenMail-Hops: 2
> >MIME-Version: 1.0
> >Content-Disposition: inline; filename="ADSM"
> >Content-Transfer-Encoding: 7bit
> >Date: Thu, 13 Jan 2000 13:06:46 +0100
> >From: "Mauro M. TINELLI" <Mauro.TINELLI AT ST DOT COM>
> >Subject: ADSM 3.1.2.50 problems.
> >To: ADSM-L AT VM.MARIST DOT EDU
> >
> >Dear(s),
> >
> >        I installed the latest release of ADSM Friday, and so far I came 
> > across
> >the following two problems. I'd like to find out if anybody of you is
> >experiencing the same behaviour:
> >
> >        Environment: NSM3466-C00 (H50, 16 x 9.1 SSA discs)
> >                     4 x 3590-1BA
> >                     Library 3494
> >        Software:    AIX 4.3.2
> >                     ADSM.server.rte    3.1.2.50
> >                          devices.rte   3.1.2.50
> >                          devices.acsls 3.1.2.50
> >
> >1) 'q sessions', sometimes shows sessions which aren't anymore
> >   connected. 'canc session' displays the message "cancelling session"
> >   without actually doing much. No connections tcp/ip can be matched
> >   using netstat (and no connection on the client side!).
> >
> >2) if it happens that I have to stop the adsm-server with drive(s) in
> >   MOUNT or IDLE state (with cartdridges loaded), and then I restart the
> >   ADSM again, I have to open the 3494 and manually unload the
> >   cartridges, because the ADSM  give the following messages for each
> >   drive:
> >
> >   ANR8469E Dismount of 3590 volume <vol-name> from drive RMT<n>
> >                          (/dev/rmt<n>) in library IBM3494 failed
> >
> >   and set them as 'unavailable since <start-up time>'
> >
> >
> >Mauro, STM
>
<Prev in Thread] Current Thread [Next in Thread>