Author |
Message
|
Prithviraj |
Posted: Sun Sep 27, 2015 7:45 pm Post subject: Where can I find MQ Error logs in z/OS |
|
|
Apprentice
Joined: 29 May 2014 Posts: 30
|
Hi all,
Could some one tell me where I can find MQ logs like logs regarding my queue, channels etc.
What is the use of MSTR job log and CHIN job log ?
Please help me. |
|
Back to top |
|
 |
vennela |
Posted: Sun Sep 27, 2015 8:52 pm Post subject: |
|
|
 Jedi Knight
Joined: 11 Aug 2002 Posts: 4055 Location: Hyderabad, India
|
You have answered the question yourself
If you need an answer more detailed than the job logs, you better start reading the MQ manuals |
|
Back to top |
|
 |
hughson |
Posted: Sun Sep 27, 2015 9:08 pm Post subject: |
|
|
 Padawan
Joined: 09 May 2013 Posts: 1959 Location: Bay of Plenty, New Zealand
|
Your subject line suggests you are looking for the equivalent to the AMQERR01.LOG file that can be found for each queue manager on a distributed platform. In these files on the distributed platforms, the queue manager and channel processes write error messages, e.g. AMQ9206 with a full description of what the administrator is expected to do as a result of seeing the message (sometime nothing needs to be done because the 'error message' was just an informational one).
On the z/OS platform the equivalent error messages are written in the MSTR and CHIN job logs. Those relating to the queue manager, logging, local queuing and QSG related facilities (to mention just a few) are written in the MSTR job log and those related to channels are written in the CHIN job log. Due to space restrictions the messages, e.g. CSQX206E are only written to these job logs with the headline, and then you must look up the message number in Knowledge Center to read what you are expected to do as a result of this message. Helpfully, each message number ends with a letter which tells you whether or not to worry about it, either I, E, A, or D. These letters mean, Infomational, Eventual Action (I.e. need to do something about it at some point), Action (need to do something about it now), and Decision (a WTOR is waiting your response right now - I think there is only one of those).
Cheers
Morag _________________ Morag Hughson @MoragHughson
IBM MQ Technical Education Specialist
Get your IBM MQ training here!
MQGem Software |
|
Back to top |
|
 |
Prithviraj |
Posted: Sun Sep 27, 2015 10:36 pm Post subject: |
|
|
Apprentice
Joined: 29 May 2014 Posts: 30
|
Thanks Hughson,
My requirement is when I put some message into a queue or while doing any other operation in Queue Manager, I expect certain messages/log relating to that operation. And I expect this message appears in MSTR and CHIN logs.
But after putting one message into a queue, I logged into spool, opened log for MSTR and checked logs in "JESMSGLG" as well as "CSQOUTX" and I did not find any logs relating to my operation.
Please guide me. |
|
Back to top |
|
 |
hughson |
Posted: Sun Sep 27, 2015 10:45 pm Post subject: |
|
|
 Padawan
Joined: 09 May 2013 Posts: 1959 Location: Bay of Plenty, New Zealand
|
An error message is not written on z/OS job logs or in the distributed platform AMQERR01.LOG files each time you MQPUT a message to a queue. Imagine how many messages that would be for some of the big financial companies who put millions of messages a day - it would be completely unworkable.
The MQPUT that an application makes is given a Completion Code and a Reason Code upon return. If these are zero you know that your MQPUT worked (transactions aside). If you truly want something written to the console for every message successfully put, it is the responsibility of your application to write such a console message.
If, on the other hand you just want to check that your message(s) arrived, you could issue the DISPLAY QSTATUS(queue-name) CURDEPTH command from SDSF and then you will see the output from that command on the MSTR job log which will tell you the current depth of the queue.
Could you say a little more about why you have the requirement for a console message per MQ message put?
Cheers
Morag _________________ Morag Hughson @MoragHughson
IBM MQ Technical Education Specialist
Get your IBM MQ training here!
MQGem Software
Last edited by hughson on Mon Sep 28, 2015 2:43 am; edited 1 time in total |
|
Back to top |
|
 |
Prithviraj |
Posted: Mon Sep 28, 2015 2:17 am Post subject: |
|
|
Apprentice
Joined: 29 May 2014 Posts: 30
|
Hi all,
Thanks Hughson,
Consider a scenario: maximum depth for a queue be 100 and an application continues to put msgs even thought the queue has reached its maximum queue depth.In this case MQ should be writing some logs, regarding the message or where the messages be moved etc. I wanted to see these messages/logs.Is there any way to see messages/logs?
Put in other words, before a queue reaching its maximum queue depth I wants to know about if from log. I know that it can be found from commands but I want to get it from logs. |
|
Back to top |
|
 |
exerk |
Posted: Mon Sep 28, 2015 2:30 am Post subject: |
|
|
 Jedi Council
Joined: 02 Nov 2006 Posts: 6339
|
Prithviraj wrote: |
Consider a scenario: maximum depth for a queue be 100 and an application continues to put msgs even thought the queue has reached its maximum queue depth. In this case MQ should be writing some logs... |
That's what event messages are for - look in the Knowledge Centre (KC) regarding monitoring queue manager events etc.
Prithviraj wrote: |
...Put in other words, before a queue reaching its maximum queue depth I wants to know about if from log. I know that it can be found from commands but I want to get it from logs. |
Have a look at a QLOCAL definition, specifically for the QDPHIEV and QDPLOEV attributes (see above). And why would you expect a queue-full condition to be logged as it's not an error condition? _________________ 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 |
|
 |
hughson |
Posted: Mon Sep 28, 2015 2:49 am Post subject: |
|
|
 Padawan
Joined: 09 May 2013 Posts: 1959 Location: Bay of Plenty, New Zealand
|
Prithviraj wrote: |
Consider a scenario: maximum depth for a queue be 100 and an application continues to put msgs even thought the queue has reached its maximum queue depth. |
Your application will receive a return code MQRC_Q_FULL in this situation and the MQPUT of the message will have failed (I.e. the message did not get put to the queue). Your application should be catching this return code and reporting it back to you.
As exerk says there are also notifications from the queue manager to tell you about a Full Queue and also about a queue that has a high depth (of your choosing) before it gets full. These notifications are not error messages in the log but event messages, for easier processing. If your requirement is to have them written to the console, there is nothing to stop you consuming the event messages and writing a console message as a result. However, you could just looking into MQ monitoring tools to do this for you. Read up about MQ Event messages.
Cheers
Morag _________________ Morag Hughson @MoragHughson
IBM MQ Technical Education Specialist
Get your IBM MQ training here!
MQGem Software |
|
Back to top |
|
 |
Prithviraj |
Posted: Mon Sep 28, 2015 11:01 pm Post subject: |
|
|
Apprentice
Joined: 29 May 2014 Posts: 30
|
Won't MQ writes any of its operations that it performs in any logs...!!!! Any logs that is helpful for a system admin...!!!! |
|
Back to top |
|
 |
bruce2359 |
Posted: Mon Sep 28, 2015 11:44 pm Post subject: |
|
|
 Poobah
Joined: 05 Jan 2008 Posts: 9469 Location: US: west coast, almost. Otherwise, enroute.
|
Yes, the qmgr and its components will log some error and non-error operations. Non-error include include channels starting and stopping. At qmgr restart, some components will write startup mags to syslog.
Consider enrolling in IBMs WM30 system admin training course. Consider downloading and reading the z/OS system admin manuals. _________________ 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 |
|
 |
hughson |
Posted: Tue Sep 29, 2015 1:59 am Post subject: |
|
|
 Padawan
Joined: 09 May 2013 Posts: 1959 Location: Bay of Plenty, New Zealand
|
Prithviraj wrote: |
Won't MQ writes any of its operations that it performs in any logs...!!!! Any logs that is helpful for a system admin...!!!! |
The queue manager writes lots of operational information to the job log. What it doesn't write is every application operation to the job log, as this would not be an appropriate use of the job log. You'd fill the spool up in minutes on a reasonably sized installation and that would drive your SysAdmins nuts! A single MQPUT is really not an interesting operation to a system admin. He is more interested in whether the page sets are getting full, or the logs have cut over and so on, things that you will see that there are messages for. He may also be interested in effects that badly written applications may cause, in which case he may additionally turn on events as earlier discussed. What he will not be interested in is being made aware of each individual MQPUT from an application - there could be many thousands, if not millions of those on a queue manager in a day.
The application developer may be interested in each individual MQPUT of a message when initially developing the app, i.e. when the first successful MQPUT is done, "yay! I got it working" and so may print out something to indicate both successful MQPUTs and of course failing ones. Once the application is developed and tested, and then rolled into production however, an output message for each MQPUT is no longer appropriate and the level of output would normally be reduced, perhaps controlled with a debug flag of some sort.
Is this helping you understand why the queue manager does not write a message to the job log for each application MQPUT?
Cheers
Morag _________________ Morag Hughson @MoragHughson
IBM MQ Technical Education Specialist
Get your IBM MQ training here!
MQGem Software |
|
Back to top |
|
 |
Vitor |
Posted: Tue Sep 29, 2015 3:38 am Post subject: |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
Prithviraj wrote: |
Won't MQ writes any of its operations that it performs in any logs...!!!! Any logs that is helpful for a system admin...!!!! |
It will write it's operations to the log. It won't write application activities to the log and I don't think the operators (sys admin is a distributed term) would like it if it did.
I echo the comments of others. Read the KC and get some training. The z/OS platform is not like distributed. _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
 |
Prithviraj |
Posted: Sun Nov 22, 2015 9:00 pm Post subject: |
|
|
Apprentice
Joined: 29 May 2014 Posts: 30
|
Hi,
What I meant in above thread is - SMF record types 115 and 116. |
|
Back to top |
|
 |
bruce2359 |
Posted: Sun Nov 22, 2015 9:19 pm Post subject: |
|
|
 Poobah
Joined: 05 Jan 2008 Posts: 9469 Location: US: west coast, almost. Otherwise, enroute.
|
What about SMF 115 and 116 records?? Are you asking where to find them? Have you asked your system programmer? _________________ 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 |
|
 |
Vitor |
Posted: Mon Nov 23, 2015 5:24 am Post subject: |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
Prithviraj wrote: |
What I meant in above thread is - SMF record types 115 and 116. |
I don't think those will go to the level you want, and I don't think that if you could make them go to the level you want the sys admins would allow it.
I'd also wonder about performing the kind of pre-emptive monitoring that you're describing from the SMF records. _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
 |
|