This provides steps to identify services that cause error "There was an inventory problem loading the PM data" in VisionWorks Classic PM - Collection Status window.
This error can be found in all versions of VisionWorks Classic PM. This will show up in the detailed Collection Status window as a Red alarm.
Example:
The services that have problem can be found by doing the following.
6. In this case there is no service with target address of "00105E01ED60-DELTA". The "DELTA" in the target address indicates the missing service is a Pseudo services. In some environments, pseudo services are created to represent a remote segment of a service where there is no direct testing. For more information reference the "Pseudo" services section in the PM Manual and Help screen for additional information on its use. The PM system can be optioned for Pseudo service ability by setting the DELTA_FLAG variable in escoutCommonProperties.txt. If the DELTA_FLAG is set, then each remote testing service (i.e. a service without direct testing) requires a pseudo service and a donor service (i.e. a service with direct testing) in order to work properly. The services get created either from the UI or from Gateway. If optioned for Pseudo services, PM expects a Pseudo service to exist if a real service has the "Reference Circuit ID" field populated with the donor service. 7. If the error is happening and the target includes the "DELTA", that means a service has Reference Circuit populated and there is no Pseudo service. To resolve, either remove the Reference Circuit from the real service or create the missing pseudo service via the Gateway or UI.
If the query for the service is not found via the Service Listings, the database will need to be searched for the service.
grep -i NOT PRRNFLAE06W-PM_PING _scout_collect.out.1 r_key='32.180.66.202.915.0.-1.-1' NOT FOUND IN INVENTORY CACHE *************
Query for targetaddr: 32.180.66.202 for Switch: PRRNFLAE06W-PM. Note: If this is in a Standalone PM environment, these steps are done on the T&D / Database Server.
echo "select * from qscope_evlan where targetaddr = '32.180.66.202' and tid_ref in (select tid_ref from qscope_schedule where tid = 'PRRNFLAE06W-PM') " | dbaccess scout
Return:
tid_ref 238 vlan_ref 245364 cktid PRRNFLAE06W/STRTFLNC0CW/USID66484/EVCPREF/00001 aav_cktid servlev_ref 1 aav 2172 targetaddr 32.180.66.202 ovlan 915 opty 0 ivlan -1 ipty -1 module PING src_ipaddr src_gateway src_subnet src_port -1 dst_port -1 stream_subtype programnum pid pidtype pcrpid encap svcid svcprov svcname status last_mod 2014-10-06 02:16:48 mod_by ADMIN locked N lock_time 2014-10-06 02:16:48 oem_ven ref_ckt_id evc_top_type market region cell_site_id comment sec_ckt_id longitude latitude active Y service_vlan
In this case the problem was the servlev_ref was invalid.
A second query shows the valid servlev_ref values:
echo "select * from qscope_servlev" | dbaccess scout service_lev servlev_ref last_mod mod_by PRIMARY_EVC 5 2012-04-06 13:56:42 ADMIN SECONDARY_EVC 6 2012-04-06 13:56:56 ADMIN MON_MSN_L_LO1 11 2012-08-20 20:38:16 ADMIN
Valid values are 5, 6, 11.
Updated the servlev_ref for the service to a valid value:
echo "update qscope_evlan set servlev = '5' where targetaddr = '32.180.66.202' and tid_ref in (select tid_ref from qscope_schedule where tid = 'PRRNFLAE06W-PM') " | dbaccess scout
Note: servlev_ref of 1 should always be valid. It is the default SLA of None and should not be deleted. If it was, here is SQL syntax to re-add the service level of 'None':
insert into qscope_servlev values ('None',1,'','ADMIN'’);
drop table if exists threshtemp; select unique qt.priority, qt.intervl, qt.type from qscope_thresh qt into temp threshtemp; insert into qscope_thresh select qm.raw_metric, 1, qt.priority, qt.intervl, qt.type, 'OFF',0,0,curr_gmt_time(),'ADMIN','N',NVL(NULL,NULL) from qscope_metric qm, threshtemp qt; drop table if exists threshtemp;
The service is now present in the GUI. Restart of collection, clears the alarm.