×
The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.
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. ..."
midrange.com
