×
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/.
midrange.com
