On 13-Apr-2016 10:29 -0500, Steinmetz, Paul wrote:
I'm working on a utility to compare object usage from production,
R&D, and the R&D source.
I found that CRTDUPOBJ or CPYLIB updates the last use date. This is
"muddying the waters" for checking actual true object usage.
In one sense, the object was actually used.
It was used to create a new duplicate object.
But in another sense, it may not have been used.
Should CRTDUPOBJ and/or CPYLIB be updating last used date?
Is there a way to tell if an object was used by an application?
The term "use" is necessarily narrowed in scope, and thus easily
argued as imperfect; not every /use/ of an object will be reflected in
the "last used" tracking, at least not conclusively\consistently from
everyone's perspective. The term "use" was purposely limited to the
_primary_ purpose\intent of the existence of the object [type], and
precludes potentially numerous /references/ to an object for which those
actions do not meet the threshold of "primary".
With few exceptions, only actions specific to the purposeful
existence of that object type are reflected as a "use" of the object of
that type. So generally, /generic/ object actions such as Move Object
(MOVOBJ), Rename Object (RNMOBJ), and Revoke Authority To Object
(RVKOBJAUT), for example, conspicuously not being specific to any
particular object type, will not impact the usage information. Note
however that a /Reference Object/ (REFOBJ) for the generic Grant
Authority To Object (GRTOBJAUT) request will be reflected as /used/; not
so, for the object to which authority is being granted.
So because the operation of /duplicate/ is generic, rather than
specific to an object type, such a /generic/ object action also would be
[expected as] atypical to be tracked as a /usage/. However there is a
specific exception made for that action of _duplicating_ an object. So
indeed, the Create Duplicate Object (CRTDUPOBJ) [and thus also Copy
Library (CPYLIB), per being implemented effectively using CRTDUPOBJ on
each successive\ordered object in the named library] typically *would*
effect an update to the Last Used Date.
There is however, yet another exception, for database files without
members, The primary purpose of the database *FILE being to store data,
when there is no data per a lack of any members, the *FILE object [which
just reflects the culmination of the underlying member objects as a
composite with the file], the *FILE object itself will not be reflected
with a current Last Used Date.
Note however, that the documentation of the exception case is listed
*prior* to the inclusive documentation about the CRTDUPOBJ:
[
http://www.ibm.com/support/knowledgecenter/ssw_ibm_i_72/rbam6/detob.htm]
"...
• Date of last use:
...
• The last used date for a database file is not updated when the
number of members in the file is zero. For example, if you use the
Create Duplicate Object (CRTDUPOBJ) to copy objects and there are no
members in the database file, the last used date is not updated.
...
Table 1. Updating usage information:
Type of object Commands and operations
--------------------- --------------------------------------------
All object types Create Duplicate Object (CRTDUPOBJ) command
and other commands, such as the Copy Library
(CPYLIB) command, that use CRTDUPOBJ to copy
objects.
..."
For any particular action for which the Last Used Date is not
updated, for which having that information updated would be desirable,
the option exists to use the The Change Object Description (QLICOBJD)
API
[
http://www.ibm.com/support/knowledgecenter/ssw_ibm_i_72/apis/qlicobjd.htm]
to update the last used date field\attribute of an external object type,
to reflect the current system date using "Key 15 (Update last used date
and days used count)".
midrange.com
