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
**********************************************************************