Printer FriendlyEmail Article Link

VisionWorks Classic PM: How to identify services that are causing error "There was an inventory problem loading the PM data".


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.



The services that have problem can be found by doing the following.

  1. Log on to the VisionWorks Classic server at the command line.  Note: If this is in a Standalone PM environment, login to the Standalone PM server.
  2. Change to the escout/logs directory.
    cd /spirent/metro/escout/logs
  3. Search for "NOT FOUND IN INVENTORY" in the collection log file.
    Format of the collection log file is:
    is the name of the SWITCH reporting the error.
    is the type of collection, such as EOAM, ETHDM, NETQ-IP, PING, TWAMP, VIDEO

    => grep "NOT FOUND IN INVENTORY"  STAC_7521_1_EOAM_1_scout_collect.out.1
    r_key='00105E01ED60-DELTA.78.0.-1.-1' NOT FOUND IN INVENTORY CACHE *************
  4. The response will show information regarding the Service that PM is attempting to update.

    In above case, one services is not found / have problem.  It has a  target address of: 00105E01ED60-DELTA and VLAN of 78 and MEG Level of 0. 
  5. The information found can be searched for in the VisionWorks Classic PM - Services List /Configuration screen to identify what is missing/wrong.


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='' NOT FOUND IN INVENTORY CACHE *************

Query for targetaddr: 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 = '' and tid_ref in (select tid_ref from qscope_schedule where tid = 'PRRNFLAE06W-PM') " | dbaccess scout


tid_ref         238
vlan_ref        245364
cktid           PRRNFLAE06W/STRTFLNC0CW/USID66484/EVCPREF/00001
servlev_ref     1
aav             2172
ovlan           915
opty            0
ivlan           -1
ipty            -1
module          PING
src_port        -1
dst_port        -1
last_mod        2014-10-06 02:16:48
mod_by          ADMIN
locked          N
lock_time       2014-10-06 02:16:48
active          Y

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 = '' 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,
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.


Product : VW Controller PM Classic