On 04 May 2013 22:54, Chamara Withanachchi wrote:
Does anyone know how to keep user profiles previous image in QAUDJRN
(CP entry is holding only the after image), is this possible or is
there an alternative to get the user profile previous image
Because the prior action of either RSTUSRPRF or CRTUSPRF would also
have been audited [presuming auditing was established when that action
was performed], that prior T-CP entry for any particular user profile
name [other than /system/ profiles] would serve as the before-image. Or
to generate such an entry because no prior entry currently
exists\remains, just issue CHGUSRPRF against all of the user profiles to
establish that first\prior entry as the /before image/ against which to
compare the next T-CP entry for each of the *USRPRF objects.
Or if the implication is that the ability should be there to see the
before image without depending on the ability to _track back_ to some
unknown prior entry [e.g. from a CRTUSRPRF a couple years ago], thus an
entry which may be long-since archived or otherwise is no longer
available in the active\online receivers, then...
If there is control over a specific program which effects the T-CP
entries of interest, then probably just issue the CHGxxxPRF [or
similarly audited] request without any explicit change; i.e. issue a
command like the CHGUSRPRF, but [defaulting or] specifying the special
value *SAME on all available parameters, in a separate request that
precedes the CHGxxxPRF that will effect the actual changes. If such a
request [which effectively changes nothing, per use of all *SAME] is not
audited, though I believe it is, then specify at least one
known\retrieved value instead of specifying the special value *SAME for
one parameter. However lacking an ability to lock the user profile
object in order to prevent concurrent changes since that value was
retrieved would be an issue of concern, if no-concurrent-changes can not
be safely assumed.
If more generally, the desire is to produce a /before image/ for any
T-CP entry that will be generated, then use of the "Change User Profile
Exit Program" with Exit Point Name: QIBM_QSY_CHG_PROFILE and Exit Point
Format Name: CHGP0100, CHGP0200 would assist to achieve that. The
latter format is a /pre-change notification/ and the former is a
/post-change notification/ which together will enable an "application
that wants to keep a prechange view of the profile to compare to the
postchange view of the profile":
http://pic.dhe.ibm.com/infocenter/iseries/v7r1m0/topic/apis/XCHGUP.htm
Within such an exit program, perhaps just issue the CHGUSRPRF or
CHGPRF with the special value *SAME [defaulted or] specified for all
available parameters. As noted above, this presumes such a request is
audited. Of course such a pre-change exit program would have to handle
recursion for that additional change profile invocation. In this manner
the two entries with the /journal code/ "T" and /entry type/ "CP" would
be in close but not necessarily immediate succession when they are
stored in the QAUDJRN.
Or, use those same exits to implement something entirely separate
from the T-CP entries; something else which can be easily compared. For
example, like Bryan suggests, the RTVUSRPRF [or the Retrieve User
Information (QSYRUSRI) API, or the DSPUSRPRF DETAIL(*BASIC)] could be
utilized to get the information in a pre-change notification, and then
used again in a post-change notification. If the information were
written to or was an update to a row in a journaled table with a primary
key on a UsrPrf field [could use CPYF MBROPT(*UPDADD) if using a row of
DSPUSRPRF output], then the CMPJRNIMG could produce a report of the
changes made over time. The SNDJRNE to a[nother] journal as Bryan
suggested, is another possible repository, but the means of comparison
is not built-in like with the CMPJRNIMG; yet there is less programming
required to get such journal logging started as compared to using a
database file.
midrange.com
