| Author |
Message
|
| krypton |
 Posted: Fri Aug 11, 2017 9:21 am Post subject: How Not to display SYSTEM objects in MQSC output? |
 |
|
Disciple
Joined: 14 Mar 2010
Posts: 186
|
Is there a way, I can hide (not display) the "SYSTEM" objects (e.g. Queues/Channels) etc when running "mqsc" command or when taking the output of dmpmqcfg command.
_________________
Dreams are not something which you watch when you are asleep,it is something which doesn't let you sleep. |
|
| Back to top |
|
 |
| bruce2359 |
| Posted: Fri Aug 11, 2017 10:25 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9470
Location: US: west coast, almost. Otherwise, enroute.
|
MQSC DISPLAY command has a WHERE option.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| krypton |
| Posted: Fri Aug 11, 2017 10:39 am Post subject: |
|
|
Disciple
Joined: 14 Mar 2010
Posts: 186
|
but it doesn't work
I tried to list all the queues which are not starting with SYSTEM and I got the error, it looks like filter_keyword "QUEUE" is not the right one.
dis q(*) where(QUEUE NE SYSTEM*)
_________________
Dreams are not something which you watch when you are asleep,it is something which doesn't let you sleep. |
|
| Back to top |
|
|
| PaulClarke |
| Posted: Fri Aug 11, 2017 11:00 am Post subject: |
|
|
Grand Master
Joined: 17 Nov 2005
Posts: 1002
Location: New Zealand
|
I think the command you should be trying is:
| Code: |
| dis q(*) where(QUEUE NL SYSTEM*) |
but I'm afraid that doesn't work either. MQSC does not support QUEUE as a filter field.
MQSCX, of course, removes all the MQSC annoyances so if you have MQSCX then you can issue
| Code: |
| dis q(*) =where(QUEUE NL SYSTEM*) |
Cheers,
Paul.
_________________
Paul Clarke
MQGem Software
www.mqgem.com |
|
| Back to top |
|
|
| mqjeff |
| Posted: Fri Aug 11, 2017 12:31 pm Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
there might be an option with dmpmqcfg. there was one with saveqmgr.
You could always use dmpmqcfg in one line mode and |grep -v 'SYSTEM.*'
_________________
chmod -R ugo-wx / |
|
| Back to top |
|
|
| krypton |
| Posted: Mon Aug 14, 2017 8:29 am Post subject: |
|
|
Disciple
Joined: 14 Mar 2010
Posts: 186
|
Thanks Jeff,
but dmpmqcfg is not useful in all cases, like when want to list current status of Queues (curdepth etc) or channels(running or retrying).
_________________
Dreams are not something which you watch when you are asleep,it is something which doesn't let you sleep. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Mon Aug 14, 2017 9:02 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| krypton wrote: |
Thanks Jeff,
but dmpmqcfg is not useful in all cases, like when want to list current status of Queues (curdepth etc) or channels(running or retrying). |
It dumps the config, not the status.
And, sorry. What I meant was that saveqmgr, and I'm pretty sure dmpmqcfg, has an option to export the configuration with each object on a separate line, so you can do a grep/find etc. to pull out all the objects with the names or other attributes youw ant.
But again. Config, not status.
_________________
chmod -R ugo-wx / |
|
| Back to top |
|
|
| krypton |
| Posted: Mon Aug 14, 2017 12:32 pm Post subject: |
|
|
Disciple
Joined: 14 Mar 2010
Posts: 186
|
Thanks, for the status commands, I have to rely on manually filtering out system objects.
_________________
Dreams are not something which you watch when you are asleep,it is something which doesn't let you sleep. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Mon Aug 14, 2017 2:00 pm Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| krypton wrote: |
| Thanks, for the status commands, I have to rely on manually filtering out system objects. |
Or using the proper syntax of the DIS command, so instead of saying "DIS QSTATUS(*)", you do something different.
Or, you know, use a non-home-built monitoring tool.
_________________
chmod -R ugo-wx / |
|
| Back to top |
|
|
| gbaddeley |
| Posted: Mon Aug 14, 2017 3:44 pm Post subject: |
|
|
Jedi Knight
Joined: 25 Mar 2003
Posts: 2538
Location: Melbourne, Australia
|
or do multiple DIS QSTATUS('XYZ*') commands for each of the app queue prefixes, so as to exclude the SYSTEM.* objects. Usually there will not be many of these prefixes.
_________________
Glenn |
|
| Back to top |
|
|
| shashivarungupta |
| Posted: Mon Aug 14, 2017 7:07 pm Post subject: |
|
|
Grand Master
Joined: 24 Feb 2009
Posts: 1343
Location: Floating in space on a round rock.
|
On Windows:
echo display queue(*) | runmqsc <QMGR NAME> | find /v "SYSTEM"
Above command may work cause it will list queues that doesn't have "SYSTEM" in its name.
'find' command on Windows with /v : Displays all lines NOT containing the specified string (here "SYSTEM").
Above command may or may not be useful cause it also spits out additional data at the end of the output of the compounded commands.
Similarly you may ignore anything in the output by scripting it on Windows or Unix based platforms.
As mentioned by @gbaddeley, you may use MQSC commands with 'String*' format to display the MQ objects.
_________________
*Life will beat you down, you need to decide to fight back or leave it. |
|
| Back to top |
|
|
| PaulClarke |
| Posted: Mon Aug 14, 2017 10:29 pm Post subject: |
|
|
Grand Master
Joined: 17 Nov 2005
Posts: 1002
Location: New Zealand
|
I wonder how much time (and therefore cost) people spend inventing these types of solutions. Not only the cost of developing the 'solution' but then the cost of maintaining them and explaining them to new-comers. And even then many of the solutions I see are approximations, or work-arounds. They rarely produce a solution which is 'ideal'.
One of the most expensive thing companies have to pay for is people's time. I know it is the "visible vs invisible cost" argument but it is a shame the lengths people (and therefore companies) will go to to avoid the cost of buying vendor products. When the 'cost' can be as little as $1 a week!
_________________
Paul Clarke
MQGem Software
www.mqgem.com |
|
| Back to top |
|
|
| exerk |
| Posted: Mon Aug 14, 2017 11:17 pm Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| PaulClarke wrote: |
| One of the most expensive thing companies have to pay for is people's time. I know it is the "visible vs invisible cost" argument but it is a shame the lengths people (and therefore companies) will go to to avoid the cost of buying vendor products. When the 'cost' can be as little as $1 a week! |
Paul, having been around a few large corporates it appears to me that they're prepared to spend inordinate amounts of money on 'enterprise frameworks', which has been hawked as the solution to everything and can never be got working down the granular level that admin teams need, rather than spend a little on tools that work; it's all about saving money apparently and centralising tooling.
I have spent countless hours giving presentations of a neat little tool that formats and presents queue manager object output, being told that it is exactly what they want, for the team to have the purchase quashed because it does not fit within the organisations tooling framework, even though a site license cost may be less than 1% of their framework costs.
Penny wise and pound foolish seems to be very apt, after all, they're already paying the people so they're not going to save anything (from their point of view, not mine).
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Tue Aug 15, 2017 3:12 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9470
Location: US: west coast, almost. Otherwise, enroute.
|
My auditor side is wondering why ignore SYSTEM objects? They can be used as functional queues, channels, ...
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| gbaddeley |
| Posted: Tue Aug 15, 2017 3:54 pm Post subject: |
|
|
Jedi Knight
Joined: 25 Mar 2003
Posts: 2538
Location: Melbourne, Australia
|
Paul, exerk, I agree with your sentiments.
There seems to be a reticence to add yet-another vendor product to the enterprise framework, largely because it requires the relationship and licensing to be managed and budgeted, and the software to be enterprise packaged, distributed, installed, and configured in a standard manner, and the usage fully documented. Even if it is a Really Good Product there needs to be a strong justification for its benefits, and to commit to the overhead.
There is also the cost of effort and outages to install software updates on 100's - 1000's of servers and for apps to do testing. Because of scale, we can only manage one software life cycle update per year, and need to choose one of our many integration s/w products to do this (usually the one that's about to go out of support).
We have quite a few legacy scripts that do funky things. No one has bothered to really understand how they work, because their authors left 10+ years ago and didn't document them. However, they still work, so we continue to use them. The down side is if they break, it takes longer to fix.
Sometimes custom scripts are the optimal solution, particularly if they are not complex, and maintenance is rarely required.
BTW, we are a MO71 licensed user.
_________________
Glenn |
|
| Back to top |
|
|
|
|
