That looks like the very one. I am not going back to try it out though. I have been through the mill with this thing and I finally capitulated and did what I clearly SHOULD have done in the very first place.
I wrote my code as a standalone monitor. Told it off to write to a log file for the specific values of the queue attributes of the specific queues, and then went for those with a script. Well I am GOING for those with a script.
I am perversely uninterested in the details of the WAS itself at this point. I have a project related problem that MUST get at the queue depths and the standard WAS interface doesn't hand those back. Not nohow. Try to get them from the admin console and you spend 5 minutes drilling into the interface.
What I really wished for and didn't get, was advice on tying into their WAS plugin.
All I needed was access to a running AdminClient to build the custom query stuff around.
Ppphhhht. ( Although that client would be affected by the problem described and my current version is immune - and can be extended in the Java to get any data I want off the WAS ).
The principle problem with any of it is that there's no way I know of to get at the queue names without programming them into the plugin. It can't discover them, present a list for the user to tick and then monitor the ticked ones. That was what I expected to do when I started. Now I have to put them into spring config files and code them into the script-plugin.
Worse, something in the WAS system is a little broken when trying to search for a specific bean. I can get ALL the beans related to SIB based queues, but I can only get a specific one by using its full ObjectName. The substring search is either too obscure or simply broken as it returns nothing.
Eh... bypassed the problem by gum. Working on the script but short of time and sleep.
Which probably has something to do with my current level of incoherence. 🙂
respectfully
BJ