| Author |
Message
|
| haqshaik |
 Posted: Thu Sep 08, 2005 11:30 am Post subject: MQ error Log |
 |
|
Novice
Joined: 08 Sep 2005
Posts: 13
|
Hi,
I am just looking at the JOBS XXXXMSTR and XXXXCHIN. I could not figure out what exactly these Jobs will keep track of. If i am opening a queue, if the open call was not successful, does the system is going to log the error in any one of these JOBs. Curretly I am just writing them into a TSqueue in CICS and displaying the same in the Batch. Can any one let me know about these Jobs and Their significance?
What is the standard procedure for handling the MQ error calls? Where do we log them? If we do not log the errors, is there any system log into which can we go and look what operation/MQ call had failed?
Any thoughts are helpful..
Thanks,
Salauddin |
|
| Back to top |
|
 |
| kevinf2349 |
| Posted: Thu Sep 08, 2005 11:53 am Post subject: |
|
|
Grand Master
Joined: 28 Feb 2003
Posts: 1311
Location: USA
|
XXXXMSTR is the Queue manager master address space and XXXXCHIN is the channel interface address space.
Neither one will report specific application type errors.
Other thoughts? Read the APG and by the sound of the question you may want to talk to your local, friendly z/OS System Programmer too  |
|
| Back to top |
|
|
| hopsala |
| Posted: Thu Sep 08, 2005 3:45 pm Post subject: Re: MQ error Log |
|
|
Guardian
Joined: 24 Sep 2004
Posts: 960
|
| haqshaik wrote: |
| What is the standard procedure for handling the MQ error calls? Where do we log them? If we do not log the errors, is there any system log into which can we go and look what operation/MQ call had failed? |
As jeff said, no application errors are logged in the jobs DD cards, as there's no real need for it; mq "skeleton" errors are logged - such as channel in retry, error in log files etc.
API errors should be handled and logged by the application (precisely like working with databases), if your MQOPEN failed, then check the error code and act accordingly, if MQPUT failed, do something else and so on.
There is no standard way of handling errors since it's different for different needs; for example, if you have a user-end application that failed on MQPUT you'd possibly simply let the user know and disconnect; conversly, if this is a batch process you may want to retry a few times, and then maybe put the msg aside and try sending another one. All this is dependant upon your buisness needs and scenario planning.
If you wish, tell us your specific scenario and ask more specific questions and we'll be glad to help; although I think you can probably handle this yourself, after a bit of reading that is. |
|
| Back to top |
|
|
| JoePanjang |
| Posted: Thu Sep 08, 2005 6:36 pm Post subject: |
|
|
Voyager
Joined: 10 Jul 2002
Posts: 88
Location: Dengkil MALAYSIA
|
we let the application to handle those errors related to MQ APIs. Then you can display the errors or messages on the cics log or tsq etc.
_________________
Every good deed is charity... |
|
| Back to top |
|
|
| haqshaik |
| Posted: Fri Sep 09, 2005 5:47 am Post subject: |
|
|
Novice
Joined: 08 Sep 2005
Posts: 13
|
Thanks Kevin for your help. Hey Joe and Hop, I underestand that we need to log somewhere the application related errors. There are various methods as mentiond. we can write the error messages in a VSAM file or a TDQ, TSQ or a DB2 table. What would be the best way to handle these errors? if you use any one of the latter said options, if there is a probelm in logging the error message, then what will happen. As Joe said, retry and leavit. Like in Batch Programs you can simply display the errors in the spool. But in CICS , DISPLAY is not acceptable verb. So I am wondering , what would be the best way?
Thanks for all your help..
I thought of Taking tips from the Gurus..
Thanks,
Salauddin |
|
| Back to top |
|
|
| hopsala |
| Posted: Fri Sep 09, 2005 10:04 am Post subject: |
|
|
Guardian
Joined: 24 Sep 2004
Posts: 960
|
Well, I don't really know what a TDQ or TSQ is (probably I do, but not in acronym form) but i'd go with a much simpler mechanism - PS (physical sequential) files. In logging, I found the simplest solutions to be the most powerful; think of an operator trying to view a VSAM file, or FTPing a database row to send to IBM...
Use something which is simplest to view, edit and transfer. Also keep in mind monitoring tools sometimes have difficulties monitoring files other than PS.
(Naturally when I see PS files, you could use CICS log, an in-house logging transaction or simply writing directly to a DD)
p.s out of interest, what are these TDQ and TSQ? |
|
| Back to top |
|
|
| haqshaik |
| Posted: Fri Sep 09, 2005 10:16 am Post subject: |
|
|
Novice
Joined: 08 Sep 2005
Posts: 13
|
Hopsala,
Thanks for providing me the feed back. I am sorry to use the acronyms.
TSQ - Temporary Storage queue
TDQ - Transient data queue.
Thanks,
Salauddin |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Fri Sep 09, 2005 10:28 am Post subject: Re: MQ error Log |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| hopsala wrote: |
| As jeff said, |
I think, for once, I didn't... 
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| hopsala |
| Posted: Fri Sep 09, 2005 10:47 am Post subject: |
|
|
Guardian
Joined: 24 Sep 2004
Posts: 960
|
(Jeff - um, of course I meant kevin! I was just testing your moderating instincts  )
Anyway - haqshaik, I have some familiarity with TSQ and TDQ, but insufficient to judge. However I repeat what I said about logging that's easy to edit, view and transport; and when I say "easy" I mean to everyone - even to people with no CICS knowledge - no sense requiring a CICS admin to view a log file... |
|
| Back to top |
|
|
| mq_developer |
| Posted: Thu Sep 15, 2005 11:09 am Post subject: |
|
|
Voyager
Joined: 18 Feb 2002
Posts: 82
|
| You can also make use of Queue Manager Events to track common MQ API failures. |
|
| Back to top |
|
|
| JoePanjang |
| Posted: Fri Sep 16, 2005 12:40 am Post subject: |
|
|
Voyager
Joined: 10 Jul 2002
Posts: 88
Location: Dengkil MALAYSIA
|
TDQ is similar to display in cics. not sure whether the current cics has new option other than TDQ(work with cics v4 last time). our mq adapter write any mq error into this TDQ.
on the logging problem, i believed TDQ/TSQ is big enough to cater for 1 day log unless during the day for every transactions there will be at least 1 error.
_________________
Every good deed is charity... |
|
| Back to top |
|
|
| kevinf2349 |
| Posted: Fri Sep 16, 2005 5:45 am Post subject: |
|
|
Grand Master
Joined: 28 Feb 2003
Posts: 1311
Location: USA
|
| Quote: |
| You can also make use of Queue Manager Events to track common MQ API failures. |
True....but only if you have them enabled first. Check with your z/OS MQ Admin person to make sure these are enabled...I believe that 'out of the box' they are disabled |
|
| Back to top |
|
|
| hopsala |
| Posted: Fri Sep 16, 2005 8:06 am Post subject: |
|
|
Guardian
Joined: 24 Sep 2004
Posts: 960
|
Indeed - by default all events are disabled (except start/stop events); but unless i'm not mistaken there are no events for API calls - you don't have an event for a failed MQOPEN, or if a msg was truncated on MQGET - that's just not what events are for. Am I wrong about this?
Anyway, using events to trace what's going on requires writing an event handler (or using the support pack) which, granted, some would consider great fun, but is by far not the best good way to debug... |
|
| Back to top |
|
|
| mq_developer |
| Posted: Fri Sep 16, 2005 11:56 am Post subject: |
|
|
Voyager
Joined: 18 Feb 2002
Posts: 82
|
| Quote: |
True....but only if you have them enabled first. Check with your z/OS MQ Admin person to make sure these are enabled...I believe that 'out of the box' they are disabled |
Yes i duly agree , i just want to post an option that is available , but inorder to make use of it you have to turn on the required queue manager events (Inhibit , Authority , Local & Remote ) and should have an event handler or monitoring tool read , process & present that information.
| Quote: |
| but unless i'm not mistaken there are no events for API calls - you don't have an event for a failed MQOPEN, or if a msg was truncated on MQGET - that's just not what events are for. Am I wrong about this |
Certainly not all the API reason codes are covered under events , but most of the common ones such as 2085 (MQOPEN failure ) , 2035 , 2082 , 2087 , 2016 ... are all covered. |
|
| Back to top |
|
|
|
|
