× 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 12-May-2016 09:08 -0500, Steinmetz, Paul wrote:
1) LF SM3UPD01 Not found in any scan source or SQL.

With regard to what /uses/ the file, such searching is inconclusive; see my recent reply.

If the files and application can be saved and restored to an alternate location to test the weekly-run, the [change in] effects can be reviewed there. If the issue persists in the test, then such a test environment also allows for changing file wait times to very large values, for which having allocated objects exclusively would delay accesses, therefore allowing review of the LCKW job(s) performing the weekly-run to be reviewed for program stack; the job(s) also could be run in debug, to expose query activity in the logging.

But I did find this.
Another LF SM3RSQ01 over the same PF STMTM3P is used by several
programs.
When the LF SM3RSQ01 is accessed by these other programs, would this
cause LF SM3UPD01 object info to be updated?

Attempt a possible answer that question, with a test: Gather\preserve a copy of the current usage info [DSPFD and DSPOBJD] for SM3UPD01, then issue the following request; afterward, compare a new collection of the usage info against the prior:

OPNDBF SM3RSQ01 *INP MBR(each_separately) ACCPTH(*FILE)
CLOF SM3RSQ01

If the usage info is updated for the other file, then that would seem a good place to concentrate, for discovering why; and provides an apparent solid re-create if necessary, to help to track down the reason.


2) Also, there is a 3rd LF SM3RTV01 which is owned by SM3UPD01
File owning access path . . . . . : BRFILES/SM3UPD01
But LF SM3RTV01 is also not used.


A /map/ of the full database relations [DSPDBR STMTM3P MBR(each_separately), and then repeated for each PFM that is a based-on for each logical file revealed in prior DSPDBR output], along with the DSPFD, DSPOBJD, DSPDBR MBR(*NONE), and DMPOBJ of every file in that DBF network\relationship might enable a reviewer to spot a lead to follow, or to expose an anomaly that potentially could cause an [seemingly] /incorrect/ LFM to be updated as /used/.


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
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.