| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
| Need help on hsMQ and MB training |
« View previous topic :: View next topic » |
| Author |
Message
|
| Dolapevich |
 Posted: Tue Oct 30, 2012 2:48 pm Post subject: |
 |
|
Novice
Joined: 29 Oct 2012
Posts: 11
Location: Buenos Aires, Argentina
|
| Quote: |
| Vitor wrote: |
| Dolapevich wrote: |
From my perspective I see it hard to understand the underlying principles and concepts of Message Queueing.
I still struggle to understand what a SRVCON is or where is the limit between qmgr and app in message format/payload. |
All three topics are covered clearly in the documentation. Even the concepts of queueing |
|
Agreed, and read, although I think more read will be needed.
| Quote: |
| Dolapevich wrote: |
| Moreover, the tool itself doesn't makes it easier; it's command nomenclature and the way it shows output data is very zOS/IBMish |
From an IBM product you would expect a consistent look and feel. I think the distributed version is much more "distributed" than z/OS (speaking as a z/OS guy)
|
With each now vendor it happens some time must be invested getting used to the way the data is displayed.
However, I don't quite understand why the multiline output has persisted across the product. Maybe is just a cosmetic thing I am having a hard time to get used.
Ex:
display qs(SYSTEM.DEFAULT.LOCAL.QUEUE)
3 : display qs(SYSTEM.DEFAULT.LOCAL.QUEUE) *1
AMQ8450: Display queue status details. *1
QUEUE(SYSTEM.DEFAULT.LOCAL.QUEUE)*1 TYPE(QUEUE)*1
CURDEPTH(0) IPPROCS(0)
LGETDATE( ) LGETTIME( )
LPUTDATE( ) LPUTTIME( )
MONQ(OFF) MSGAGE( )
OPPROCS(0) QTIME( , )
UNCOM(NO)
*1 yes, I already know
Same information can be displayed on a line, which in turn allows to grep for the data you need.
Logs is another example of the same thing. Most of them are multilined:
ej:
----- amqccita.c : 3276 -------------------------------------------------------
10/30/2012 07:49:11 AM - Process(23221.540) User(mqm) Program(amqrmppa)
AMQ9209: Connection to host 'somehost (10.208.3.11)' closed.
EXPLANATION:
An error occurred receiving data from 'cdrhld001 (10.208.3.11)' over TCP/IP.
The connection to the remote host has unexpectedly terminated.
ACTION:
Tell the systems administrator.
--
Yes, I learned to grep by the error code that thankfully contains the offender host, but I can't know when it happened.
| Dolapevich wrote: |
Just sharing my perspective.
To which you're entirely welcome. Note also the RFE system on developerWorks allows you to not only get this perspective to a wider audience, but is a platform for any suggestions you may have to improve the product. It's newcomers like yourself who have the clearest perspective. |
Will check that, thanks for the suggestion  |
|
| Back to top |
|
 |
| Dolapevich |
| Posted: Tue Oct 30, 2012 3:16 pm Post subject: |
|
|
Novice
Joined: 29 Oct 2012
Posts: 11
Location: Buenos Aires, Argentina
|
| Quote: |
Those of us of a certain age grew up with stdin and shell scripting.
Those of us with experience in certain markets avoid utilities that come with that kind of license. Because organizations in those markets are filled with guys in grey suits with geometrical imaginations.
Everything you want to do can be done with scripts. I'll take your word this other thing is easier. |
I thought so about the gay, sorry, gray suits.
But it looks there are people out there with a bunch of imagination.
Found this today: http://www-01.ibm.com/support/docview.wss?uid=swg21302912
That lead me to: http://www.greenend.org.uk/rjk/sw/withreadline.html
Will try and report.
Thanks. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Wed Oct 31, 2012 4:18 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
at least on newer versions on windows, runmqsc does have command history - I can easily within a given session hit the 'up' arrow and cycle through previous commands, and then the down arrow to go forward.
But fundamentally, it remains that the recommended practice for using runmqsc is to use it in shell scripts that use stdin/stdout redirection. Because you should make changes in repeatable and audit-able ways that can themselves be made subject to change control.
To that extent, the output format doesn't matter - as long as it's predictable enough to handle meaningfully in scripts. |
|
| Back to top |
|
|
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
