ADSM-L

Re: Expire inventory "features"

1999-10-12 09:44:33
Subject: Re: Expire inventory "features"
From: "Magura, Curtis" <curtis.magura AT LMCO DOT COM>
Date: Tue, 12 Oct 1999 09:44:33 -0400
Becky,

   We are running 3.1.2.22 for 3590-E support. Don't know if that will help
you out or not. I wanted to go to .40 to use the duration feature of
expiration but after watching the list I'm staying put for now. I think we
will end up going to Tivoli Storage Manager 3.7 on the server instead.......
Anybody got there yet ? I put up one NT client so far and like everyone else
would like to have the admin gui back for certain functions.

Curt Magura
Lockheed Martin
Enterprise Information Systems
Gaithersburg Md.
301-240-6305


                -----Original Message-----
                From:   Becky Buechler [mailto:Buechlerb AT SCHNEIDER DOT COM]
                Sent:   Tuesday, October 12, 1999 8:52 AM
                To:     ADSM-L AT VM.MARIST DOT EDU
                Subject:        Re: Expire inventory "features"

                Richard,

                I am having the same problem with the database growing so
fast. However I
                can't go back to my previous level since I need 3.1.2.41 for
the new 3590-E
                tape drives.  I have tried to isolate the EXPIRE INVENTORY
process but it
                is hard and I am tired of baby-sitting ADSM all day.

                I CAN NOT understand how IBM can keep releasing new versions
that cause so
                many problems. Do they test this software at all? I would
think the problem
                we are seeing is pretty obvious if they ran tests.  Now I
have to wait for
                3.1.2.42 to be released and see what other problems this
release causes! I
                was told that 3.1.2.40 and up was suppose to be bug free
before I went to
                it.



                Becky Buechler
                Schneider National Inc.
                buechlerb AT schneider DOT com
                920-592-8331




                                    ADSM-L AT VM DOT MAR
                                    IST.EDU              To:     Becky
Buechler/Schneider@Schneider,

ADSM-L@ADSM-L AT VM.MARIST DOT EDU@SMTP@exchange
                                    10/12/1999           cc:
                                    03:35 AM             Subject:      Re:
Expire inventory "features"





                I posted the same problem on the list on the 24/25 August
this year.  I had
                upgraded all my ADSM servers (SP nodes, AIX 4.1.5 and 4.3.1)
to 3.1.2.40,
                however expiration just did not work.  It hung and could not
be cancelled.
                As a result my database just got bigger and bigger.

                On the advice of IBM I "isolated" the expiration process.
However the only
                way to solve the problem was to regress 5 of the ADSM
servers to 3.1.2.20.
                IBM in the UK spoke to the ADSM developers and I was quoted
the same APAR
                (IC24611) on Sun Solaris.

                I tried everything to fix this problem, but you'll probably
have to regress
                to 3.1.2.20.  It seems totally random as to which servers
are affected.

                Richard.


                =====================================
                Technical Services (ADSM) - Dawson House
                Int: 33298  Ext: 01925 233298
                =====================================

                > -----Original Message-----
                > From: Dhanoa, Jasdayal Singh
[SMTP:jasdayal.dhanoa AT WCOM.CO DOT UK]
                > Sent: 11 October 1999 14:49
                > To:   ADSM-L AT VM.MARIST DOT EDU
                > Subject:      Re: Expire inventory "features"
                >
                > I sometimes get the problem described below. My server is
an IBM SP Node,
                > AIX 4.3.1.
                > The ADSM server is at 3.1.2.41. Is there an APAR for this
?
                >
                > Regards
                >
                > Jasdayal S Dhanoa
                > MCI WorldCom
                >
                > > -----Original Message-----
                > > From: Becky Buechler [SMTP:Buechlerb AT SCHNEIDER DOT COM]
                > > Sent: Thursday, October 07, 1999 3:39 PM
                > > To:   ADSM-L AT VM.MARIST DOT EDU
                > > Subject:      Re: Expire inventory "features"
                > >
                > > Here is what I have learned after upgrading to V3.1.2.41
two weeks ago.
                > > If
                > > I run expiration with any other processes it will hang
the 'expire
                > > inventory' process.  If I try to cancel it the 'expire
inventory'
                > process
                > > will stay in a cancelling state until I recycle ADSM.
According to IBM
                > > there is an APAR out there for my problem and it only
occurs on Sun
                > > servers. IC24611.
                > >
                > > I like the idea of the expiration enhancements but it is
causing more
                > > problems than it is fixing.
                > >
                > > Becky Buechler
                > > Schneider National Inc.
                > >
                > >
                > >
                > >
                > >
                > >
                > >
                > >                     ADSM-L AT VM DOT MAR
                > >                     IST.EDU              To:     Becky
                > > Buechler/Schneider@Schneider,
                > >
                > > ADSM-L@ADSM-L AT VM.MARIST DOT EDU@SMTP@exchange
                > >                     10/06/1999           cc:
                > >                     09:00 PM             Subject:
Expire inventory
                > > "features"
                > >
                > >
                > >
                > >
                > >
                > > Hi... has anyone noticed these (err) features with the
inventory
                > > expiry under 3.1.2.40?
                > >
                > > Feature #0:
                > >
                > >         Expire inventory works through the nodes in the
order they were
                > >         registered;  first registered is expired first.
                > >
                > >
                > > If you cancel an EXPIRE INVENTORY process and restart it
some time
                > > later it will pick up where it left off.  This is a good
thing.  But
                > > leads to feature #1:
                > >
                > >         ADSM starts at the beginning of the file space
it was last
                > >         examining.
                > >
                > > Therefore, if you have a regime in which expiry is run
every day, is
                > > cancelled after 4 hours and have a file system that
takes (say) 5
                > > hours to examine, then ADSM will stay stuck on that one
file system.
                > >
                > >
                > > But wait, if you order now you can get feature #2 for no
extra cost!
                > >
                > >
                > > If you use 'expire inventory duration=nnn' and
expiration is cancelled
                > > because it has exceeded the duration, you get feature
#2:
                > >
                > >         The next expiration starts from the beginning of
the node list.
                > >
                > > So if you try to use duration=nnn to control
expirations, you will
                > > just expire the same set of file systems over and over
again.
                > >
                > >
                > >
                > > And feature #3 (at least on my system)
                > >
                > >         The server leaks memory if expire inventory and
client
                > >         sessions run concurrently.
                > >
                > > ... our ADSM server [process] has crashed three
Saturdays in a row.
                > > Each time the server process has grown from a sedate
128MB-140MB
                > > footprint to 570MB+ and paging madly.
                > >
                > > If expire inv is not running, no Satuday crash.  (I
don't have the
                > > courage to run expire inv during a weekday backup window
;)
                > >
                > >
                > > Before I try to raise this with IBM service, does anyone
else see
                > > these sorts of effects?
                > >
                > > You probably need a large client base --- we have ~600
clients and a
                > > 30GB database, so small sites and test systems won't
show it up.
                > >
                > >
                > > Russell
                >
                > ===================================================
                > This communication contains information which is
confidential and
                > may also be privileged.  It is for the exclusive use of
the
                > intended recipient(s).  If you are not the intended
recipient(s),
                > please note that any distribution, copying or use of this
                > communication or the information in it is strictly
prohibited.
                > If you have received this communication in error, please
notify
                > the sender immediately and then destroy any copies of it.

**********************************************************************
                This email and any files transmitted with it are
confidential and
                intended solely for the use of the individual or entity to
whom they
                are addressed. If you have received this email in error
please notify
                the system manager.

                This footnote also confirms that this email message has been
swept by
                MIMEsweeper for the presence of computer viruses.

                www.mimesweeper.com

**********************************************************************
<Prev in Thread] Current Thread [Next in Thread>