While the "USM device specific or group alarm tab" views queries the NAS_ALARMS table only on the 'dev_id', The ListViewer reports alarm needs to match the "met_id" as well.
Possibly, in these cases, the ListViewer is trying to pull any alarm that match a met_id for a different QOS.
If the ListViewer was created to show, for example, targets for the qos 'QOS_URL_RESPONSE', then an 'alarm column' in the report will pull out from the database alarms with a 'met_id' of the target's rows in the S_QOS_DATA table.
There are also cases where the probe is sending the alarms for "wrong" met_id as the met_id will depend on which QOS is activated. Normally it should default to the Response time met_id (if it is active)
In any case, f the met_id the ListViewer is looking for doesn't match the met_id printed on the alarm generated by the probe, the alarm won't show in the ListViewer.
The resolution to this problem depends on how the ListViewer Report was built.
However, one of these actions may solve the mismatch problem:
1) Deactivate any QOS in the profile, deactivate the profile, save.
2) Aknowledge any alarm from the target
2) Deactivate the probe
3) Start the probe.
4) Activate the QOS again and check again
Possibly, this will create a probe "reset" so that the alarm will be generated with the met_id the list viewer is looking for.
1) The source used for the Alarm can be forced in the URL_response probe > Go to the Advanced tab
2) in Source override, set, for example, $url
3) Aknowledge any alarm from the target
This will possible override the dev_id and met_id to the one that match the URL