Re: DSPDBR question

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

We have a file with a logical with no library associated with it on
the DSPDBR command. This file with no library is driving our MIMIX
nuts ! The Administrator has requested that we fix this file.

We can recreate the file in the correct library and it shows on the
DSPDBR, but we cannot figure out where the one without a library is
to delete it.

We tried DLTF *ALL/filename. All it did was delete the one we want
in the library.

<<SNIP>> <ed: DSPDBR ACOM/FOPPYD MBR(*NONE) RCDFMT(*NONE) output:>>

Dependent File Library Dependency JREF Constraint
FOPPYDL1 ACOM Data
FOPPYDL2 ACOM Data
FOPPYDL3 Data
FOPPYDL3 ACOM Data

The database logical file FOPPYDL3 that shows no library name is in the OS development parlance, "out of context"; i.e. the object is not currently inserted into a context, aka not inserted into a library.

Is the physical file journaled? If so, the journal may include some information about the creation [and its failure to progress]. The condition is /normal/ but may be abnormal; possibly being the normal effect of interrupted work or work performed under isolation [e.g. DROP VIEW or DROP INDEX], or possibly being interrupted work for which no recovery is being tracked.

I could give some information about how to track down the creation time of the file, and the user that owns the object; that can enable finding joblogs, messages, journal, and\or audit entries that can provide more information. That starts with: DMPOBJ ACOM/FOPPYD *FILE

One phase of RCLSTG SELECT(*ALL) OMIT(_whatever_) will both complete interrupted database work [i.e. work performed under commitment control or under non-commit database recovery] and will regain addressability to the object by inserting the database *FILE object into a context; i.e. the object would appear in QRCL [or QRCL##### in an iASP] after that request. There is another means to effect the same with less impact, but that requires knowing the owner; i.e. the prior activity I alluded to obtain that info:

<http://pic.dhe.ibm.com/infocenter/iseries/v7r1m0/topic/cl/rclobjown.htm>
Reclaim Objects by Owner (RCLOBJOWN)
"The Reclaim Objects by Owner (RCLOBJOWN) command checks the objects owned by a user profile to make sure those objects which must be in a library are actually in one. ..."