Thanks. We're doing some system cleanup, and one of the libraries being
deleted has this scenario. Looks like we'll wait for a maintenance window to
run the RCLSTG.
Paul Nelson
Cell 708-670-6978
Office 409-267-4027
nelsonp@xxxxxxxxxxxxx
-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of
CRPence
Sent: Thursday, March 26, 2015 2:32 PM
To: midrange-l@xxxxxxxxxxxx
Subject: Re: Phantom logical files
On 26-Mar-2015 14:10 -0500, Paul Nelson wrote:
Does anyone recall why a DSPDBR on a physical file can yield the name
of a logical that doesn't have a library name associated with it?
I remember hearing the reason long ago, but I can't recall now.
The Dependent [Logical] File [depending on the Display Database
Relations (DSPDBR) command parameter specifications, the file(s) listed
may not necessarily be an LF] is "not in a context". The condition is a
/problem/ only if the dependent file is not _pending_ creation or
deletion [under isolation\commitment-control or database recovery].
Irrespective the nature of the condition, a full Reclaim Storage
(RCLSTG) would resolve the condition.
To determine something about the file, the space object at the
address of the entry in the *DBDIR corresponding to the x/1901 database
*FILE object for which no Library name is listed, can be dumped using
the LIC formatted dump; the owner, creation date\time, and the
modification date\timestamp should all be included in that output.
Unfortunately the pointer to the Database Recovery Object is not stored
in the *FILE object that is being operated upon under dbrcy\cmtctl :-(
so WRKCMTDFN *ALL is about the only way to find a possible CmtDfn under
which the resource is tracked, or tooling to locate all of the x/19D4
objects with the common prefix [¿ QDBDBDROBJ ?] and the name of the file
across all of the libraries.
midrange.com
