Re: DSPDBR question

On 25-Mar-2014 09:32 -0700, Cyndi Bradberry wrote:

We have a <ed: physical> file with a logical <ed: file> with no
library associated with it on <ed: as presented by> the DSPDBR
command. This file with no library is driving our MIMIX nuts!
The Administrator has requested that we fix this file. <<SNIP>>

If the logical file had been dropped under isolation, pending COMMIT [or ROLLBACK], then a feature depending on the output of the database file or member relations should not have any difficulty with that file; i.e. the effect whereby a logical file name appears without a library name, is entirely valid for a delete database file request being performed under commitment control. A request to Work With Commitment Definitions (WRKCMTDFN) for *ALL jobs across the system could be used to identify the pending work as validly awaiting a COMMIT or ROLLBACK of the request against that database *FILE name as an object resource. If the job is active, then the job performing work under isolation should be listed in the locks on the physical file [member]. If the job is inactive and the recover is pending either due to the operation not running under isolation or commitment control was not allowed to complete its implicit rollback, then the issue is more abnormal than normal.

Any problems for a feature due to the described condition [if the underlying physical file is not locked under isolation] could be resolved by moving the existing file and addressable relations to another [permanent] library, and then recovering the file from a backup [restore the objects and authorities and apply journaled changes]; the save activity for the backup could be taken immediately without any ill effects, avoiding the need to apply journal entries.