Uhmmmm so did you have things set to require a backup prior to a file being
migrated ?
If so in your pinch you could probably delete the stubs and restore the file
(or restore with the replace option)

Dwight

> ----------
> From:         John Miley[SMTP:john AT GEOSC.PSU DOT EDU]
> Reply To:     ADSM: Dist Stor Manager
> Sent:         Wednesday, August 23, 2000 4:32 PM
> To:   ADSM-L AT VM.MARIST DOT EDU
> Subject:      access denied to space managed files
>
> Hello All,
>
> We are running ADSM 3.1.2.50 under Solaris 2.6 and the HSM client version
> 3.1.0.8 also under Solaris 2.6.
>
> Recently we've developed a problem accessing our space managed files.
> Regardless of permissions and ownership we get errors like:
>
> shannon[80]# dsmrecall 16fxyd03.3dv
> ADSTAR Distributed Storage Manager
> space management Interface - Version 3, Release 1, Level 0.8
> (C) Copyright IBM Corporation, 1990, 1999. All Rights Reserved.
>
>  ** Unsuccessful **
> ANS4007E Error processing
> '/shannon/d3/lgcproject/3dvs/kileuea/16fxyd03.3dv': access to t
> he object is denied
>
>
> I can migrate files but once they are in server storage, cannot recall
> them, regardless of when they were migrated.
>
> Other seemingly related symptoms of the problem are that I cannot
> successfully reconcile the space managed filesystem, it hangs indefinitely
> with no errors reported.  I also cannot generate a list of files for
> recall via the HSM GUI.
> An incremental backup of the space managed file system also fails with
> "Internal Error:  Please contact your service representative", which we
> have.  This issue has currently gone to IBM level 2 support but I figured
> I would run it by the list as well on the chance that someone else has
> experienced this problem.
>
>  We believe it started shortly after we hit the default quota for the HSM
> storage pool.  When I discovered that we had done so I immediately doubled
> it and files started migrating.  At the time I didn't believe there was
> any fallout but in retrospect we don't think anything has been
> successfully recalled since then.
>
> The storage pool in question has the following attributes:
>
>
> q stgpool 3590HSM f=d
> ANR2017I Administrator SERVER_CONSOLE issued command: QUERY STGPOOL
> 3590HSM f=d
>
>                Storage Pool Name: 3590HSM
>                Storage Pool Type: Primary
>                Device Class Name: 3590
>          Estimated Capacity (MB): 690,435.6
>                         Pct Util: 13.3
>                         Pct Migr: 16.0
>                      Pct Logical: 100.0
>                     High Mig Pct: 90
>                      Low Mig Pct: 70
>                  Migration Delay: 0
>               Migration Continue: Yes
>              Migration Processes:
>                Next Storage Pool:
>             Reclaim Storage Pool:
>           Maximum Size Threshold: No Limit
>                           Access: Read/Write
>                      Description: Space Management Pool for Magstar
>                Overflow Location:
>            Cache Migrated Files?:
>                       Collocate?: No
>            Reclamation Threshold: 60
>  Maximum Scratch Volumes Allowed: 50
>    Delay Period for Volume Reuse: 0 Day(s)
>           Migration in Progress?: No
>             Amount Migrated (MB): 0.00
> Elapsed Migration Time (seconds): 0
>         Reclamation in Progress?: No
>  Volume Being Migrated/Reclaimed:
>   Last Update by (administrator): ADMIN
>            Last Update Date/Time: 02/17/00 17:03:55
>
>
> The Pct Logical 100.0 value has me concerned.  Is that a problem?
>
>
> Anyway, if anyone has any insight into this problem we would appreciate
> comments and suggestions.  Thanks alot.
>
>
> John Miley
> Sys Admin
> PSU Geosciences
>