We are using cisco works LMS 3.1 and Hum version 1 in our network.
In common service Job information status, we getting error
1019.2306 QUICK_INTERFACE_UTILIZATION_REPORT_JOB Failed
1189.265 QUICK_INTERFACE_AVAILABILITY_REPORT_JOB Failed
These errors are generated in Common Services form Hum and After clicking the Job ID ,no information is displayed .
Please help to solve this Error.
There will be log files in the HUMReports directory in the standard log file location. They should correspond to your job ID. Please post them.
There are no errors here, but these are not from the jobs for which you earlier reported a problem. you mentioned jobs 1019 and 1189. Is 1188 also showing as failed? If so, enable Report Jobs debugging under HUM > Admin > Log level Settings, and run one of the failing jobs again. The new log file should have more details.
The first log looks like the job data was removed from the HUM database. That is, creating a new job with the same parameters should succeed. Have you ever reinitialized the upm database?
The second log doesn't necessarily indicate a problem. It could be that for this run, there was no threshold violation data available (i.e. between Aug 10 13:03:01 and Aug 11 13:03:01).
How can we re-initialize the UPM database (we have never done it)
Their is UPMlog which is nearly 320kb and we are unable to delete it. When we shutdown the crmdmgtd service the log was automatically deleted and when again service started log reappears.
we have not set any thresholds in HUM up till now, but even then should this show as 'Failed' (RED) in the CiscoWorks Page? This seems pretty strange that if there are no thresholds set/violations the report task would show as failed?
To reinitialize the upm database, you would have to have run:
NMSROOT/bin/perl NMSROOT/bin/dbRestoreOrig.pl dsn=upm dmprefix=UPM
I can't see another way that the job info would have been removed from the upm database, but not from JRM.
The jobs reporting failed with no data should be fixed in HUM 1.1 (part of LMS 3.1). There was an internally found bug relating to this. There is also an upcoming 1.0.1 release which should also contain the fix.
I'm not saying you should reinitialize your DB. My thought was that perhaps the database was already initialized which would explain the discrepancy between it and JRM.
If you need these reports to run again, try recreating them as new job instances.