Hi Rob,
With the POR happening on the CF the recovery of the structures is unavoidable. However, in chatting with some of my collegues we came up with a suggestion! To avoid having to issue the recover cfstruct command manually you could put it in the INP2 dataset so that it gets issued automatically at queue manager startup. If the structure doesn't require recovery then the command will just get ignored, and also if it isn't the last queue manager to start then it will be ignored. If it is the last queue manager to be started then the recovery will take place. Usual caveat applies! Please test this first before using it in production!
Thanks
Paul
Paul Dennis
WebSphere MQ for z/OS Development
IBM Hursley
| "Gordon, Robert -
Tech Services" <[EMAIL PROTECTED]>
Sent by: MQSeries List <[email protected]> 24/02/2006 15:21
|
|
Paul: Thanks for your reply. Our CF is a CF LPAR, and I am doing the RECOVER CFSTRUCT in only one of the QMGRs in a QSG pair (each QSG only has one application structure). The recovery is working OK; I was just looking for something I could do procedurally to avoid having to do the recoveries, but the way you explained this, I can see why it has to happen.
Thanks.
-Rob
From: Paul S Dennis [mailto:[EMAIL PROTECTED]
Sent: Thursday, February 23, 2006 11:51 AM
Subject: Re: Message CSQE035E - failed structure
Hi Robert,
It sounds like the problem you are seeing is due to a POR of the coupling facility where the MQ structures are stored. Do you have a separate CF, or is it a CF LPAR on your main box? I am afraid that if the CF loses the structures (in your case due to the POR) then MQ has no choice but to fail them and hence require recovery.
However, there are some things that you can do which will make things easier. Firstly, issuing the BACKUP CFSTRUCT command just before the POR is exactly the right thing to do as this will mean that there won't be much recovery required for the structures. When the machines have been IPLed you will need to restart all of the queue managers that are in the QSG, this is so that the Admin structure can be fully rebuilt. Each queue manager rebuilds their own entries in the CF. Until all of the queue managers have been started it won't be possible to recover the failed application structures. Having restarted all the queue managers you can issue the RECOVER CFSTRUCT command on a single queue manager in the QSG to recover all of the application structures. You can specify multiple structures in the recover command and hence only need to read the logs once. You simply specify the names of the structures, separated by a comma eg RECOVER CFSTRUCT(APPL1,APPL2,APPL3) to recover the structures APPL1 through APPL3.
Hope this helps a little, although it is probably not the answer you were hoping for.
Thanks
Paul
Paul Dennis
WebSphere MQ for z/OS Development
IBM Hursley
| "Gordon, Robert -
Tech Services" <[EMAIL PROTECTED]> Sent by: MQSeries List <[email protected]> 23/02/2006 15:47
|
|
Greetings. We’re running WMQ 5.3.1 on z/OS 1.4 in a queue-sharing-group environment and every time we do a power-on-reset, several of our queue managers need application structure recovery. Our development environment has 32 queue managers across 2 LPARs so it gets to be a bit of a pain. I’ve opened an ETR with IBM about this and basically got a reply of “that’s the way it is when you do a POR”. I can’t believe that. Has anyone else had this experience and has anyone found a way to prevent this? I’ve tried issuing the BACKUP CFSTRUCT command just before the POR but it doesn’t seem to help at all.
Thank you.
Regards,
Robert Gordon
Citizens Bank
Use of email is inherently insecure.
Confidential information,
including account information, and personally identifiable information,
should not be transmitted via email, or email attachment. In no event
shall Citizens or any of its affiliates accept any responsibility for
the loss, use or misuse of any information including confidential
information, which is sent to Citizens or its affiliates via email, or
email attachment. Citizens does not guarantee the accuracy of any email
or email attachment, that an email will be received by Citizens or that
Citizens will respond to any email.
This email message is confidential and/or privileged. It is to be used
by the intended recipient only. Use of the information contained in
this email by anyone other than the intended recipient is strictly
prohibited. If you have received this message in error, please notify
the sender immediately and promptly destroy any record of this email.
Instructions for managing your mailing
list subscription are provided in the Listserv General Users Guide available
at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html
Use of email is inherently insecure.
Confidential information,
including account information, and personally identifiable information,
should not be transmitted via email, or email attachment. In no event
shall Citizens or any of its affiliates accept any responsibility for
the loss, use or misuse of any information including confidential
information, which is sent to Citizens or its affiliates via email, or
email attachment. Citizens does not guarantee the accuracy of any email
or email attachment, that an email will be received by Citizens or that
Citizens will respond to any email.
This email message is confidential and/or privileged. It is to be used
by the intended recipient only. Use of the information contained in
this email by anyone other than the intended recipient is strictly
prohibited. If you have received this message in error, please notify
the sender immediately and promptly destroy any record of this email.
Instructions for managing your mailing list subscription
are provided in the Listserv General Users Guide available at http://www.lsoft.com
Archive: http://listserv.meduniwien.ac.at/archives/mqser-l.html
