Oh, this one might be from a problem I'm experiencing...

     I have some disk volumes within some storage pools where I went to
     remove those volumes from their associated storage pool.

     Standard process:
     vary offline somevolser
     upd volume somevolser acc=reado
     vary online somevolser
     move data somevolser
        (move data process starts & ends with no errors)
     del vol somevolser
        (return code 13, volume still contains data)
     move data somevolser
        (0 bytes moved... volume contains no data!)
     del vol somevolser
        (return code 13, volume still contains data)
     audit volume somevolser fix=yes
        (volume contains no data!)
     del vol somevolser
        (return code 13, volume still contains data)
     vary offline somevolser
     upd vol somevolser acc=destroyed
     del vol somevolser discard=yes
        (return code 13)

     So some ADSM internal still thinks data exists but it don't !

     I haven't seen it on any "tape" volumes, only some disk volumes.
     Seeing how a reclamation is basically a move data, these are probably
     one and the same...

     I haven't seen any "lost" data.  Currently not very worried... they
     probably just exit some loop prior to flip'n some "has data" flag
     'cause all the routines to "move data" can't find any, yet data D.N.E.
     hence my belief it is just a bum flag value somewhere and not actual
     lost data

     later,
           DWight


______________________________ Reply Separator _________________________________
Subject: Re: serious volume problem
Author:  PrathW1 (PrathW1 AT CENTRAL.SSD.JHUAPL DOT EDU) at unix,mime
Date:    4/9/99 10:05 AM


I am confused about this thread.
I just pulled the full text of the APAR from IBM- link.

The APAR TITLE says ADSM is deleteing volumes with files that can't be
reclaimed.
But the  "Problem Description" section (keep reading) says the message is
misleading, and all the data was reclaimed.

Can anybody confirm whether we should actually be concerned about missing
data here?

****************************************************************************
***************
IBM text:
Item IX84765
  APAR Identifier ...... IX84765 Last Changed..99/02/01   <<...>>
  IF A VOLUME CONTAINS FILES WHICH COULD NOT BE RECLAIMED, ADSM
  SERVER 3.1.2.0 WILL DELETE THE VOLUME FROM THE STORAGEPOOL.

  Symptom ...... IN INCORROUT         Status ........... CLOSED  PER
  Severity ................... 3      Date Closed ......... 99/01/28
  Component .......... 576556402      Duplicate of ........
  Reported Release ......... 310      Fixed Release ............ 999
  Component Name ADSM AIX(V4) SE      Special Notice
  Current Target Date ..99/02/23      Flags
  SCP ................... AIXRSC
  Platform ............ AIX

  Status Detail: Not Available

  PE PTF List:

  PTF List:
  Release 310   : PTF not available yet


  Parent APAR:
  Child APAR list:


  ERROR DESCRIPTION:
  If a volume contains files which could not be reclaimed, ADSM
  Server 3.1.2.0 will delete the volume from the storagepool.
  Messages from the actlog:
  ANR1175W Volume xxxx contains files which could not be reclaimed
  ANR1410W Access mode for volume xxxx now set to "unavailable".
  ANR1041I Space reclamation ended for volume xxxx.
  ANR1341I Scratch volume xxxx has been deleted from storage pool.


  LOCAL FIX:
  none


  PROBLEM SUMMARY:
  ****************************************************************
  * USERS AFFECTED:                                              *
  All ADSM V3
  ****************************************************************
  * PROBLEM DESCRIPTION:                                         *
  ANR1175W Volume xxx contains files which could not be reclaimed
  ANR1410W Access mode for volume xxx now set to "unavailable".
  ANR1041I Space reclamation ended for volume xxx.
  ANR1341I Scratch volume xxx has been deleted from storage pool.

  The ANR1175W message is misleading since all of the data was
  moved from the volume.
  ****************************************************************
  * RECOMMENDATION:                                              *
  Apply fixing PTF when available.
  ****************************************************************
  Changed the condition causing the message to be a retriable
  condition to prevent the message from being issued in those
  cases where the message was not necessary.




****************************************************************************
*************************************************
> -----Original Message-----
> From: Henk ten Have [SMTP:hthta AT SARA DOT NL]
> Sent: Friday, April 09, 1999 10:42 AM
> To:   ADSM-L AT VM.MARIST DOT EDU
> Subject:      Re: serious volume problem
>
> On 09-Apr-99 Richard Sims wrote:
> >>  1) If a volume with valid data is deleted from the primary storage
> pool,
> >>     how can I get this data back from the copy storage pool?
> >
> > Deletion of files from the primary storage pool means instant expiration
> > for their images in the copy storage pool - gonzo.
>
>   Ok, good point. But how can I be sure that those (valid) files did
>   really expire their images in the copy storage pool? And that they
>   really disappear from the primary pool?
>   I mean, how can I check that? Yes, maybe I'm suspicious, but I
>   do not always believe what ADSM likes me to believe :-(
>
> >>  2) Is there a consistency check between a primary storage pool and his
> >>     copy storage pool?
> >
> > Just Backup Stgpool.
>
>   Hm, that's not what I mean: how can I be sure that all data on the
>   copy pool is also on the primary pool? (Well, I suppose Backup Stgpool
>   will expire data which is found on the copy pool and which is not found
>   on the primary pool)
>
>   Cheers,
>   Henk ten Have.