Re: Phantom logical files

Chuck,

Good info.

Another question about DSPDBR showing a dependent logical twice.

Couple of months ago I ran across DSPDBR on a single physical file that
yielded over 20 logicals AND one of those logicals was listed twice as a
Dependent file, same library, same dependency. I'm unaware on how I could
create that situation on purpose...

Files Dependent On Specified File

Dependent File Library Dependency JREF Constraint


We have not run RCLSTG since discovering this, it's not an issue for us,
just an anomaly.




On Thu, Mar 26, 2015 at 1:40 PM, Paul Nelson <nelsonp@xxxxxxxxxxxxx> wrote:

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.

--
Regards, Chuck
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.



--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.