Compliance Manager ZOS_MONITOR LINKLIST reporting query
Article ID: 95954
Updated On:
Products
Compliance Manager for z/OS
Issue/Introduction
I know the product we use as 'Compliance Manager R2 for z/OS' and this is a query relating to started task CMGRMON (Monitor).
We have a policy statement in force as follows: Event = ZOS_MONITOR Condition = LINKLIST=Y PUUID = c57ee523-b5d5-4917-aa25-f2d2a191a649 Action = EMAIL
We are interested in changes made to the LINKLIST concatenation,
I know the product we use as 'Compliance Manager R2 for z/OS' and this is a query relating to started task CMGRMON (Monitor).
We have a policy statement in force as follows: Event = ZOS_MONITOR Condition = LINKLIST=Y PUUID = c57ee523-b5d5-4917-aa25-f2d2a191a649 Action = EMAIL
We are interested in changes made to the LINKLIST concatenation, and we can see that from time to time, rows are added to these DB2 tables:
HDRDELTA LSTDELTA SNGDELTA
We can use the following SQL to retrieve data regarding LINKLIST dataset changes: SELECT DATE(HDR.EVTTIMESTAMP) AS DATE ,TIME(HDR.EVTTIMESTAMP) AS TIME ,HDR.EVTSYSID AS SYSID ,HDR.EVTPOLICY AS POLICY ,SUBSTR(LST.LSTKEY1,1,44) AS LSTKEY1 ,SUBSTR(LST.LSTKEY2,1,20) AS LSTKEY2 ,LST.LSTCHGTYPE AS LSTTYPE ,LST.LSTCATEGORY AS LSTCAT ,LST.LSTOPTION AS LSTOPT ,SNG.SFDOPTION AS SFDOPT FROM,CMGRQ1.HDRDELTA,HDR ,CMGRQ1.LSTDELTA LST ,CMGRQ1.SNGDELTA SNG WHERE DATE(HDR.EVTTIMESTAMP) > (CURRENT DATE - 120 DAYS) AND DATE(HDR.EVTTIMESTAMP) < (CURRENT DATE - 1 DAYS) AND HDR.EVTREFTBL = 'L' AND HDR.EVTREFID = LST.LSTPARENTID AND LST.LSTCHGTYPE LIKE '%' AND LST.LSTREFID = SNG.SFDPARENTID AND LST.LSTOPTION = 'LINKLIST_DATASET' AND SNG.SFDPARENTTBL = 'L' ORDER BY DATE, TIME WITH UR;
We notice that (for example) the data indicates that: - On March 26th, SYS1.LINKLIB on volume RES001 was added -
On May 7th, SYS1.LINKLIB on volume RES001 was deleted - On May 28th, SYS1.LINKLIB on volume RES002 was added
These were all Sundays in 2017 and they are dates when IPLs were done.
On May 7th a SYSRES switch was also done (previous SYSRES was RES001, IPL was done from RES002) Now in the real world, probably every zOS shop in the world has SYS1.LINKLIB as a permanent fixture in their linklist, but it is common to switch SYSRES volumes on some IPLs in order to bring in scheduled maintenance. My question is: Why is the data being reported like this? I would understand if an UPDATE were reported for the date when the SYS1.LINKLIB volume switched from RES001 to RES002, but the data implies that for 3 weeks (between May 7th and May 28th) we were operating without SYS1.LINKLIB in our LINKLIST concatenation.
I have chosen a very specific example - the dates are real, the SYSRES volumes are edited but hopefully the example is clear.
Similar data is found for LPALIST and APF datasets which reside on our SYSRES volumes.
We regard these data as 'false positives' and are really only interested in cases where a dataset disappears permanently from our LINKLIST concatenation, or where a new one appears.
Please can you explain why the data is being recorded this way?
We have a policy statement in force as follows: Event = ZOS_MONITOR Condition = LINKLIST=Y PUUID = c57ee523-b5d5-4917-aa25-f2d2a191a649 Action = EMAIL
We are interested in changes made to the LINKLIST concatenation,
I know the product we use as 'Compliance Manager R2 for z/OS' and this is a query relating to started task CMGRMON (Monitor).
We have a policy statement in force as follows: Event = ZOS_MONITOR Condition = LINKLIST=Y PUUID = c57ee523-b5d5-4917-aa25-f2d2a191a649 Action = EMAIL
We are interested in changes made to the LINKLIST concatenation, and we can see that from time to time, rows are added to these DB2 tables:
HDRDELTA LSTDELTA SNGDELTA
We can use the following SQL to retrieve data regarding LINKLIST dataset changes: SELECT DATE(HDR.EVTTIMESTAMP) AS DATE ,TIME(HDR.EVTTIMESTAMP) AS TIME ,HDR.EVTSYSID AS SYSID ,HDR.EVTPOLICY AS POLICY ,SUBSTR(LST.LSTKEY1,1,44) AS LSTKEY1 ,SUBSTR(LST.LSTKEY2,1,20) AS LSTKEY2 ,LST.LSTCHGTYPE AS LSTTYPE ,LST.LSTCATEGORY AS LSTCAT ,LST.LSTOPTION AS LSTOPT ,SNG.SFDOPTION AS SFDOPT FROM,CMGRQ1.HDRDELTA,HDR ,CMGRQ1.LSTDELTA LST ,CMGRQ1.SNGDELTA SNG WHERE DATE(HDR.EVTTIMESTAMP) > (CURRENT DATE - 120 DAYS) AND DATE(HDR.EVTTIMESTAMP) < (CURRENT DATE - 1 DAYS) AND HDR.EVTREFTBL = 'L' AND HDR.EVTREFID = LST.LSTPARENTID AND LST.LSTCHGTYPE LIKE '%' AND LST.LSTREFID = SNG.SFDPARENTID AND LST.LSTOPTION = 'LINKLIST_DATASET' AND SNG.SFDPARENTTBL = 'L' ORDER BY DATE, TIME WITH UR;
We notice that (for example) the data indicates that: - On March 26th, SYS1.LINKLIB on volume RES001 was added -
On May 7th, SYS1.LINKLIB on volume RES001 was deleted - On May 28th, SYS1.LINKLIB on volume RES002 was added
These were all Sundays in 2017 and they are dates when IPLs were done.
On May 7th a SYSRES switch was also done (previous SYSRES was RES001, IPL was done from RES002) Now in the real world, probably every zOS shop in the world has SYS1.LINKLIB as a permanent fixture in their linklist, but it is common to switch SYSRES volumes on some IPLs in order to bring in scheduled maintenance. My question is: Why is the data being reported like this? I would understand if an UPDATE were reported for the date when the SYS1.LINKLIB volume switched from RES001 to RES002, but the data implies that for 3 weeks (between May 7th and May 28th) we were operating without SYS1.LINKLIB in our LINKLIST concatenation.
I have chosen a very specific example - the dates are real, the SYSRES volumes are edited but hopefully the example is clear.
Similar data is found for LPALIST and APF datasets which reside on our SYSRES volumes.
We regard these data as 'false positives' and are really only interested in cases where a dataset disappears permanently from our LINKLIST concatenation, or where a new one appears.
Please can you explain why the data is being recorded this way?
Environment
Z/OS
Resolution
The z/OS and ESM monitors (zos in this issue) captures the current system settings, LNKLST, LPALST, APFLST, SVCs, etc, on a timed basis.
When the timer pops, the monitor takes a snapshot of memory and compares the current values to the value previously captured and stored as a ‘baseline’ in the database.
If differences are found between the current values and the previous baseline, policy is checked to determine *if* the change should be logged in the database across the 5 tables mentioned above and well as any alerts that are to be sent, or is policy not interested in the specific event, If not interested, the change details are not kept, BUT the baseline is updated to the latest set of values.
If no changes are detected between the current values and baseline, no policy is checked and the baseline is not updated/changed.
With that as the background, we can now review what happens when differences are detected for your specific case, LNKLST. When differences are detected, you can have 3 scenarios.
One, the removal of DSNs only.
Two, the addition of DSNs only.
Third, the removal of DSNs and the addition of DSNs.
egardless of the first or third scenario, the removal (DELETE) of a DSN causes a ‘D’ record to be written with the date/time of the last baseline.
Regardless of the second or third scenario, the addition (ADD) of a DSN causes a ‘A’ record to be written with the current date/time.
The use of the baseline date/time for the delete and current for the add allows you to read it as you have been running without the specific DSN (SYS1.LINKLIB) in the LNKLST, but that’s not how to interpret the data. The delete was detected at the same time as the add, the data is letting you know when the dataset being removed/deleted was last part of a past baseline.
When the timer pops, the monitor takes a snapshot of memory and compares the current values to the value previously captured and stored as a ‘baseline’ in the database.
If differences are found between the current values and the previous baseline, policy is checked to determine *if* the change should be logged in the database across the 5 tables mentioned above and well as any alerts that are to be sent, or is policy not interested in the specific event, If not interested, the change details are not kept, BUT the baseline is updated to the latest set of values.
If no changes are detected between the current values and baseline, no policy is checked and the baseline is not updated/changed.
With that as the background, we can now review what happens when differences are detected for your specific case, LNKLST. When differences are detected, you can have 3 scenarios.
One, the removal of DSNs only.
Two, the addition of DSNs only.
Third, the removal of DSNs and the addition of DSNs.
egardless of the first or third scenario, the removal (DELETE) of a DSN causes a ‘D’ record to be written with the date/time of the last baseline.
Regardless of the second or third scenario, the addition (ADD) of a DSN causes a ‘A’ record to be written with the current date/time.
The use of the baseline date/time for the delete and current for the add allows you to read it as you have been running without the specific DSN (SYS1.LINKLIB) in the LNKLST, but that’s not how to interpret the data. The delete was detected at the same time as the add, the data is letting you know when the dataset being removed/deleted was last part of a past baseline.
Feedback
Yes
No
Powered by
