I recently had the same type of experience. I don't know for sure what I
did to cause the problem. IBM suggested (as a last resort) to audit the
data base, which hogged the system all day, and did not fix anything.

The next day I was poking around in the admin graphical interface. When
I went to exit from the reclamation tab of the 3570 pool it asked if I
wanted to save changes. I did not think I had changed anything, but I
went ahead & let it save. - That appeared to fix the problem. IBM
support did not understand it. - All I know is that 3570 reclamation
works again...

Dennis Knee
Information Technology
Church of the Nazarene


"Dusedau, Stefan" wrote:
>
> Bo,
>
> "Pool id 6" refers to the internal id assigned by ADSM. I did use a show
> command once that did something with these but I can't remember what it was.
> It sounds like an error that I would forward to your ADSM support group.
>
> Thank You,
>
> Stefan
>                 -----Original Message-----
>                 From:   Bo Ossinger [mailto:ossinger AT WSU DOT EDU]
>                 Sent:   Tuesday, March 23, 1999 3:24 PM
>                 To:     ADSM-L AT VM.MARIST DOT EDU
>                 Subject:        Storage Pool Id not found
>
>                 We just moved our primary storage pools from 3570 tape
> libraries to a 3575.
>                  We used both MOVE DATA and IMPORT/EXPORT to load the new
> storage pools,
>                 then deleted the old storage pool definitions.  Now when we
> restart the
>                 server we get:
>
>                 03/23/1999 11:34:13  ANR9999D asutil.c(210): Pool id 6 not
> found.
>                 03/23/1999 11:34:13  ANR9999D afmigr.c(1081): Error
> obtaining attributes for
>                                       pool (6).
>                 03/23/1999 11:34:13  ANR1062W Error initiating space
> reclamation for storage
>                                       pool  - internal server error
> detected.
>                 03/23/1999 11:34:13  ANR1042I Space reclamation for storage
> pool  will be
>                                       retried in 60 seconds.
>
>                 No, we never had a stgpool named "6" -- it appears to have
> lost the name.
>                 The attempted reclamation does not continue, and it doesn't
> appear to
>                 impact our normal operations, but I'd like to remove the
> "ghost."  Has
>                 anyone seen this one before?
>
> ====================================================================
>                 Bo R. Ossinger                 phone: 509-335-0920
>                 Washington State University    fax:   509-335-6635,,,50920
>                 Information Technology         mailto:ossinger AT wsu DOT edu
>                 Production Support Systems
> http://www.wsu.edu/prod_supp/Pss.html
>                 PO Box 641222
>                 Pullman, WA  99164-1222
>
> ====================================================================