| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
| Challenge Question - 09 / 2008 |
View previous topic :: View next topic |
| Author |
Message
|
| Challenger |
 Posted: Thu Sep 25, 2008 12:38 am Post subject: Challenge Question - 09 / 2008 |
 |
|
Centurion
Joined: 31 Mar 2008
Posts: 115
|
I am back from 3.5 weeks away !
Since I am quite late doing the September one , I have decided to offer 2 relatively easier challenge questions for your consideration (there will be 2 prizes offered as well of course)
The First one:
My company has been developing WMQ applications for several years now, and we now have a significant number of WMQ programs. Some time ago we lost a number of messages after a Queue Manager crashing due to a disk failure. After a lot of research, we found out that somebody had changed the attributes of a model queue to “non-persistent”, and that several programs did not explicitly set the persistence. What can we do to avoid this problem in the future (shooting someone is not a valid suggestion, or is it?)?
Note: feel free to (positively and constructively) argue in favor of / against options offered by other contributors… Extra bonus points would be awarded.
The Second one:
We’re running a heterogeneous network with queue managers at various versions (but all 5.3 or higher) on a variety of platforms (Solaris, Win 2003 Server, Win XP, AIX 5.2 and 5.3 and HP/UX). Gievn how most people on the forums seem to like Exits in general, after some decent testing on all platforms, we implemented an API Exit that writes an alert to the Windows Event Log / Unix syslog whenever the application writes a message to the “Application Error Queue” (this happens very rarely, at most a few times a day). Everything seems to be running fine, except… some AIX based users complain about slow response times. Any idea what could have caused this?
Good Luck.
ps: October Challenge has been lined up, a real nice treat and not for the fainthearted ones   . You will have to do some serious thinking for that one, keep an eye out for it - should be interesting. |
|
| Back to top |
|
 |
| Gaya3 |
| Posted: Thu Sep 25, 2008 12:57 am Post subject: Re: Challenge Question - 09 / 2008 |
|
|
Jedi
Joined: 12 Sep 2006
Posts: 2493
Location: Boston, US
|
| Challenger wrote: |
The First one:
My company has been developing WMQ applications for several years now, and we now have a significant number of WMQ programs. Some time ago we lost a number of messages after a Queue Manager crashing due to a disk failure. After a lot of research, we found out that somebody had changed the attributes of a model queue to “non-persistent”, and that several programs did not explicitly set the persistence. What can we do to avoid this problem in the future (shooting someone is not a valid suggestion, or is it?)?
|
1. Especially for the Production queue mangers, I will come up with a script which gives me an alert about the objects (Queues, channels, Process etc) if its gets altered.
2. This alert script check the ALTDATE, CRDATE and Current Date like wise it will send a report by comparing those (certain logic)
3. Sends the report which contains queue/channel/process details where it got altered.
4. We can investigate/question/discuss the same at that point itself and do the necessary changes if required.
_________________
Regards
Gayathri
-----------------------------------------------
Do Something Before you Die |
|
| Back to top |
|
|
| exerk |
| Posted: Thu Sep 25, 2008 1:28 am Post subject: Re: Challenge Question - 09 / 2008 |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| Gaya3 wrote: |
1. Especially for the Production queue mangers, I will come up with a script which gives me an alert about the objects (Queues, channels, Process etc) if its gets altered.
2. This alert script check the ALTDATE, CRDATE and Current Date like wise it will send a report by comparing those (certain logic)
3. Sends the report which contains queue/channel/process details where it got altered.
4. We can investigate/question/discuss the same at that point itself and do the necessary changes if required. |
That could be too late, by the time that all interested parties are involved and agreements made/knuckle rapped, message loss could re-occur; I would augment 2. by automating the change back to persistence.
Shooting is too quick. What about death by reading IBM manuals 
_________________
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 |
|
|
| dgolding |
| Posted: Thu Sep 25, 2008 1:50 am Post subject: |
|
|
Yatiri
Joined: 16 May 2001
Posts: 668
Location: Switzerland
|
We have a similar system, but something to watch out for is having only ALTDATE and ALTTIME come up on the diff - this could be because (for instance) an XMITQ has been get disabled and then re-enabled while in re-try - you want to throw ALTDATE/TIME-only entries away, otherwise you get too much noise....
Wouldn't it be nice if the product had an audit trail, that told you who (not "mqm") when and what was changed..... |
|
| Back to top |
|
|
| exerk |
| Posted: Thu Sep 25, 2008 2:13 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| dgolding wrote: |
| Wouldn't it be nice if the product had an audit trail, that told you who (not "mqm") when and what was changed..... |
Or the ability to define a queue as permanently persistent, which could only be changed by a delete/redefine? Perhaps one for the wish-list...
_________________
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 |
|
|
| AkankshA |
| Posted: Thu Sep 25, 2008 4:15 am Post subject: Re: Challenge Question - 09 / 2008 |
|
|
Grand Master
Joined: 12 Jan 2006
Posts: 1494
Location: Singapore
|
| Challenger wrote: |
The Second one:
We’re running a heterogeneous network with queue managers at various versions (but all 5.3 or higher) on a variety of platforms (Solaris, Win 2003 Server, Win XP, AIX 5.2 and 5.3 and HP/UX). Gievn how most people on the forums seem to like Exits in general, after some decent testing on all platforms, we implemented an API Exit that writes an alert to the Windows Event Log / Unix syslog whenever the application writes a message to the “Application Error Queue” (this happens very rarely, at most a few times a day). Everything seems to be running fine, except… some AIX based users complain about slow response times. Any idea what could have caused this?
. |
whats the CSD level for MQ 5.3 and 6 ???
i remember facing somwhat similar issue last year on 5.3 which was fixed in CSD 14 for AIX IIRC
_________________
Cheers |
|
| Back to top |
|
|
| atheek |
| Posted: Thu Sep 25, 2008 4:20 am Post subject: |
|
|
Partisan
Joined: 01 Jun 2006
Posts: 327
Location: Sydney
|
| Quote: |
The Second one:
We’re running a heterogeneous network with queue managers at various versions (but all 5.3 or higher) on a variety of platforms (Solaris, Win 2003 Server, Win XP, AIX 5.2 and 5.3 and HP/UX). Gievn how most people on the forums seem to like Exits in general, after some decent testing on all platforms, we implemented an API Exit that writes an alert to the Windows Event Log / Unix syslog whenever the application writes a message to the “Application Error Queue” (this happens very rarely, at most a few times a day). Everything seems to be running fine, except… some AIX based users complain about slow response times. Any idea what could have caused this? |
Any chance this is of a MQ product bug?
I could see this APAR for v 5.3 on AIX:
http://www-01.ibm.com/support/docview.wss?&apar=only&uid=swg1IY74915 |
|
| Back to top |
|
|
| AkankshA |
| Posted: Thu Sep 25, 2008 4:20 am Post subject: Re: Challenge Question - 09 / 2008 |
|
|
Grand Master
Joined: 12 Jan 2006
Posts: 1494
Location: Singapore
|
| Challenger wrote: |
The First one:
My company has been developing WMQ applications for several years now, and we now have a significant number of WMQ programs. Some time ago we lost a number of messages after a Queue Manager crashing due to a disk failure. After a lot of research, we found out that somebody had changed the attributes of a model queue to “non-persistent”, and that several programs did not explicitly set the persistence. What can we do to avoid this problem in the future (shooting someone is not a valid suggestion, or is it?)?
. |
How about not granting the mqm rights to all somebody s
having spl access mechanisms for model queues especially...
_________________
Cheers |
|
| Back to top |
|
|
| Michael Dag |
| Posted: Thu Sep 25, 2008 5:57 am Post subject: |
|
|
Jedi Knight
Joined: 13 Jun 2002
Posts: 2607
Location: The Netherlands (Amsterdam)
|
how about remembering Queues are not persistent, Messages can be!!!
if you don't want to lose a message, set it in the application, not rely on default queue definitions! 
| Quote: |
| My company has been developing WMQ applications for several years now... |
you should know better then!
_________________
Michael
MQSystems Facebook page |
|
| Back to top |
|
|
| exerk |
| Posted: Thu Sep 25, 2008 6:13 am Post subject: Re: Challenge Question - 09 / 2008 |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| Challenger wrote: |
The First one:
...and that several programs did not explicitly set the persistence... |
...implies that this is not possible, or at least within the short term.
_________________
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 |
|
|
| Mr Butcher |
| Posted: Thu Sep 25, 2008 7:00 am Post subject: |
|
|
Padawan
Joined: 23 May 2005
Posts: 1716
|
for the first one
change the copy member / macro for the MD and make the default a non existing value. this will result in a compile error.
to give an example for z/OS Assembler: the original section in the macro looks like this:
| Code: |
EDIT MQS.SCSQMACS(CMQMDA) - 01.00 CHARS 'PERS' found
Command ===> Scroll ===> CSR
060000 &PRIORITY=MQPRI_PRIORITY_AS_Q_DEF, X
065000 &PERSISTENCE=MQPER_PERSISTENCE_AS_Q_DEF, X
070000 &MSGID=00, X |
this could be changed into
| Code: |
EDIT MQS.SCSQMACS(CMQMDA) - 01.00 CHARS 'PERS' found
Command ===> Scroll ===> CSR
060000 &PRIORITY=MQPRI_PRIORITY_AS_Q_DEF, X
065000 &PERSISTENCE=SPECIFY_A_VALUE_FOR_PERSISTENCE, X
070000 &MSGID=00, X |
....
in addition, the MQPER_PERSISTENCE_AS_Q_DEF constant should be removed from the proper copy books.
instead of changing it to something invalid forcing a compile error a valid value could be used, e.g. MQPER_PERSISTENCE as a new default
_________________
Regards, Butcher |
|
| Back to top |
|
|
| mqjeff |
| Posted: Thu Sep 25, 2008 7:10 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| Which copy member does JMS use? |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Thu Sep 25, 2008 7:42 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| ... (shooting someone is not a valid suggestion, or is it?)? |
What follows is a non-technical view of this issue - my opinion.
There is no effective technical solution for bad application coding.
Given all other qmgr things working correctly, message persistence is THE issue for message survival.
As tech manager (and with no real authorit to do so), I would review source code in TEST to ensure that it met established standards. And I would not allow apps to percolate into QA (and PROD) that failed to meet standards.
If your organization has one, the performance review process is where this can be effectively managed: coach, counsel, terminate. I also had a rubber mallet on my desk for programmer attitude adjustment.
Beyond the technical issue, it's a business, after all.
_________________
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 |
|
|
| PeterPotkay |
| Posted: Thu Sep 25, 2008 10:05 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
Can an MQ Admin guarantee the message's persistence attribute? No. (well, you could if you have an MQ API Exit, but lets not go there)
Because of that reason, right then and there you make a stand and say that all MQ messages's persistence attribute is the sole responsability of the application. Period. Done. End of discussion (end of discussion not here, but when you are dealing with the business). Any app that can't code the few keystrokes it takes to set persistence yes or no is lazy, either too lazy to code it or too lazy to make a decision of whether they need to make them persistent or not. Why should the MQ Admin shoulder this responsability, especially when they can't do anything about it at the end of the day to inusre the persistence one way or the other?
_________________
Peter Potkay
Keep Calm and MQ On
Last edited by PeterPotkay on Thu Sep 25, 2008 10:57 am; edited 1 time in total |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Thu Sep 25, 2008 10:24 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
As a follow-on to PeterPotkay's comment:
If the programmer had coded the business process calculations in error, and those errors made it into an MQ message, would you still involve (blame) the MQ Admins? Of course not.
I don't believe it's too much to ask of programmers to write competent code.
_________________
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 |
|
|
|
|
|
 |
Goto page 1, 2, 3 Next |
Page 1 of 3 |
|
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
|
|
|
|
