RE: LF usage -- MIDRANGE-L

Chuck,

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.

On our R&D system, I had the same weekly processes run, SM3UPD01 LF object usage indicated the object was NOT used.

Since object auditing didn't tell me anything on Production LPAR,
I've created a scheduled job, that runs every minute.

DSPOBJD OBJ(BRFILES/SM3UPD01) OBJTYPE(*ALL) DETAIL(*FULL) OUTPUT(*PRINT)

Next week, on 5/25, our next weekly process, I will now have a time stamp to the minute, showing when this object is used.
Using DSPLOG, I should be able to match the timestamp to the processes that run, should be able to determine which process is causing the object usage.

Any thoughts from the group?

Paul

-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of CRPence
Sent: Friday, May 20, 2016 12:00 PM
To: midrange-l@xxxxxxxxxxxx
Subject: Re: LF usage

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