Audit SMF records - QWHCTOKN question

Tim Hare

Audit SMF records - QWHCTOKN question

I understand that the SMF records for IFCID 143 (first change) and 144 (first read) are really "first after a COMMIT".  Can we use QWHCTOKN to determine that we have records from the same unit of work / program / transaction / etc. ?
In other words, if two or more records have the same QWHCTOKN values, can we 'roll them, up' ?

Venkat Srinivasan

RE: Audit SMF records - QWHCTOKN question
(in response to Tim Hare)

I am not sure why you want to roll up. Since audit is for an event, it should not (probably) be rolled up nor tinkered in any way at all.

qwhctokn is primarily used to match the db2 record with the corresponding cics record. It will also work if there is inter db2 (zos) requester / server connectivity but i think that logic may break in ddf access. Isnt part of the token is sent by client and you can get into the issue of multiple client environment and the uniqueness problem thereof.
if you roll up based on qwhctokn it may work for some but may break for some by causing conflicts.

I dont think you should roll up and summarize. 

Venkat
In Reply to Tim Hare:

I understand that the SMF records for IFCID 143 (first change) and 144 (first read) are really "first after a COMMIT".  Can we use QWHCTOKN to determine that we have records from the same unit of work / program / transaction / etc. ?
In other words, if two or more records have the same QWHCTOKN values, can we 'roll them, up' ?

Tim Hare

RE: Audit SMF records - QWHCTOKN question
(in response to Venkat Srinivasan)

We are not, in this instance, auditing the use, as in an actual audit.  We're trying to determine who uses a certain set of tables as part of an impact analysis for migrating an application, and we're looking a count of uses in a week.  If one 'QWHCTOKN' has multiple 143/144 records because of COMMITs, that inflates the count for that application.  If I can roll it up to indicate one 'use' per QWHCTOKN, and indicate update yes/no by the presence of a 143 record, then we have what we want.

Venkat Srinivasan

RE: Audit SMF records - QWHCTOKN question
(in response to Tim Hare)

Tim, qwhctokn will be of no value for what you want to achieve.
You can track qwhslucc. If you look at the prod section standard header,
here is the mapping dsect for qwhslwid.

QWHSLWID   DS 0CL24 LUWID
QWHSNID      DS CL8 NETWORK ID
QWHSLUNM  DS CL8 LUNAME
QWHSLUUV  DS XL6 UNIQUENESS VALUE
QWHSLUCC  DS FL2 COMMIT COUNT          ======>This will be unique for a uow

For the same application, across all units of work as in the combination of (qwhsace,qwhsssid,first 22 bytes of qwhslwid,qwhcopid,qwhccv and qwhcplan ),
qwhslucc will vary. ace can also be reused in a very busy system. You may want to add euid, enduser workstation etc to maintain sequence for dbats.
Some distributed programs are notorious where some qwhccv values show up in uppercase
while some records showing up with lower case.


Another way to spot the distinct uow is to check the log rba posted as part
of 143 data record.
For the same application thread, log rba in 143(first change ifcid) will differ
for each unique unit of work.
Log rba in a 144 (first read) can be legally zero on a read only thread.
Looking at logrba alone may fail in first read records.
Hope this helps.

Venkat