× 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.



Is there a logical file in QTEMP on some job that has not completed. QTEMP is a different object and if you create a temporary logical file in QTEMP, how would it display in the DSPDBR?

There is a way to get to QTEMP objects, but I do not remember how to.

I believe an IPL would be required to clean up the housekeeping.

Darryl Freinkel
Sent from my iPad

On Mar 27, 2015, at 9:08 AM, Paul Nelson <nelsonp@xxxxxxxxxxxxx> wrote:

The drop table doesn't work. I get an SQL0204 message that the file is not
found. When I try to DSPPFM on the file, I get famous "Pointer not set for
location referenced" message.

Looks like this will wait until April 11th when we do PTF's (from last
June's cumulative) and a 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: Friday, March 27, 2015 7:54 AM
To: midrange-l@xxxxxxxxxxxx
Subject: Re: Phantom logical files

On 26-Mar-2015 14:40 -0500, Paul Nelson wrote:
On Thursday, March 26, 2015 2:32 PM CRPence wrote:
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.

Thanks. We're doing some system cleanup, and one of the libraries
being deleted has this scenario.

I should have added that the Database Recovery phase of an IPL does
the followup of both the commit definitions and the database recovery
objects; i.e. if the condition has not spanned a pwdwn\IPL already, then
the next IPL will locate all the DBrcy\CmtCtl and process them. Thus
deferring to the IPL to find them rather than doing that oneself, is an
option. As well, a dedicated\restricted-state reclaim of just the
*DBXREF [i.e. RCLSTG SELECT(*DBXREF)] should process any of those
objects as well; if nothing pending exists, to track the out-of-context
Logical File object, there will be no benefit, but maybe worse [yet
possibly inconsequential], is that when the file [with the blank library
name] is eventually deleted, that would be a condition for which the
Database Cross Reference would be marked in-error [per msg CPF32A3 or
msg CPF32A2] because a DBF was deleted for which the corresponding row
in the QADBXREF file was not found, thus vitiating the effect of the
prior RCLSTG SELECT(*DBXREF).

Anyhow, I had responded originally with an assumption that the intent
was to find out the meaning\origin for the condition. I had not
responded as if the intent were merely to bypass a msg CPF3219 condition
for which a Clear Library (CLRLIB) or the Delete File (DLTF) [as
requested by that or a Delete Library (DLTLIB)] request could not be
effected. If there is no need to better understand the scenario and\or
the origin, then issuing the following SQL request to attempt to remove
the database physical *FILE object [that will not delete] might suffice:

DROP TABLE the_PF_Named_on_DSPDBR_request CASCADE

If either the dependent LF is in DB recovery [but only to another
active job for which the partially created or partially deleted file is
locked] or the LF is under CmtCtl [irrespective of the status of the job
owning the CmtDfn, such that even zero locks may persist], then the
cascaded DROP would also fail. However the failure would be for an
allocation error [like msg CPF3203 or CPF3204] or the "pending changes"
msg CPF325E; the "pending recovery" msg CPF3245 should not be possible
for the LF per the lack of a context [aka library] for the system
pointer to the LF in the directory. Barring any locks or pending
Commit\Rollback required, because the /delete-DBF/ operation is coded to
be /tolerant/ [i.e. to complete despite certain classes of errors], the
Physical File would be deleted irrespective the outcome for the
dependent LF, when using the DROP CASCADE]. Noting however, that the
/tolerance/ for errors might leave orphaned storage, possibly causing
the owner to see msg CPI2235 logged for Work With Objects By Owner
(WRKOBJOWN), and possibly if the other code-path was updated to do so as
well, then that msg also seen for a request to Display User Profile
(DSPUSRPRF) for Type Of Information (TYPE) specified as *OBJOWN.

Looks like we'll wait for a maintenance window to run the RCLSTG.

I recommend avoiding if possible, the /full/ reclaim request [i.e.
RCLSTG SELECT(*ALL) OMIT(whatever)]; operate instead, with an intention
to indefinitely postpone that long-running request. Per the stated
intention to effect deletion, the DROP with CASCADE would be my first
choice as a means to avoid the full reclaim.

FWiW: If the object owner, crt dts, and mod dts were to be obtained
from the formatted dump of the space [the space located from the system
pointer found in the Dump Object (DMPOBJ) of the PF] then knowing when
the file was created and thus if an IPL had already occurred-since,
would suggest if an IPL alone might resolve the condition; if the file
has already spanned an IPL, then apparently not, except if the SCPF [and
history] logged errors with database recovery that can be prevented for
an upcoming IPL. With such info comes a possibility to track the job
that caused the issue, including possibly determining the library into
which the create\delete activity originally failed and thus in what
library could be found the DB recovery object; from dumping the recovery
object, even more possibly could possibly be gleaned.

--
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.


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.