To have a easy way to know which targets in scope were unreachable during the discovery

Due to processing by IBM, this request was reassigned to have the following updated attributes:
Brand - Cloud
Product family - Operations Management
Product - Tivoli Application Dependency Discovery Mgmt (TADDM)

For recording keeping, the previous attributes were:
Brand - WebSphere
Product family - ITSM Operations
Product - Tivoli Application Dependency Discovery Mgmt (TADDM)

You could base a report on differences between on differences between BB_COMPUTERSYSTEM40_V and BB_OPERATINGSYSTEM62_V.

Whenever a Ping discovery is run, BB_COMPUTERSYSTER40_V receives an update when the DNS entry still exists, but as long as the OSSensor is not run, the lastmod date of BB_OPERATINGSYSTEM62_V is not updated.

We use this to identify login problems, but it could work for your purpose as well, assuming you're using L2 discovery. Good luck!

ps. I'm not an IBM employee or representative :)

The query:
select
A2.FQDN_C, A2.CONTEXTIP_C , A2.LASTMODIFIEDTIME_T as "SYSTEM MODIFIEDTIME", A1.LASTMODIFIEDTIME_T as "OS MODIFIEDTIME", A1.OSCONFIDENCE_C
from cmdb.bb_operatingsystem62_v A1
join cmdb.BB_COMPUTERSYSTEM40_V A2 on a1.PK_C = A2.PK__OSRUNNING_C
where
-- Time difference between system update and os update is more than 2 days:
(A2.LASTMODIFIEDTIME_C - A1.LASTMODIFIEDTIME_C) >= 2*3600*24*1000
and
A1.osconfidence_c = 100
and
-- where not interested in systems that haven't been seen at all for 21 days.
A2.LASTMODIFIEDTIME_C >= (((TRUNC(sys_extract_utc(SYSTIMESTAMP),'MI') - to_date('01-JAN-1970','DD-MON-YYYY')) * (86400) * (1000)) - (21*3600*24*1000))