MQ start in disaster recovery scenario

[Garcia Juanino, Jorge]

Hello:

It's my first post in this fórum. Our experience in MQ z/OS is low and we have a lot of questions about the MQ manage.
The first is about the recover process in a disaster recovery scenario with high activity in channels and queues. In our test scenario when we replicated the MQ devices to a disaster recovery site and there was a high activity, the manager start in a disaster recovery lpar failed with a system abend (we don't remember the code) about consistency of RBA . The workaround was to replicate device in a time with a low activity. In this situation the manager start always works fine.
My question is about a real disaster recovery situation. The channels and queues are with a lot of message in fly. In this scenario we suppose that it's impossible support the messages consistency in MQ channels and queues and you must execute a MQ cold start. Our question is, what's the way to do a MQ cold start? Define a new BSDS, LOG and PSID? Only one of them? Start the manager with a new parm?

Regards

Jorge Garcia Juanino
Gerente sistemas z/OS
ACTP - DIAC - Operación y Soporte EMEA
MAPFRE
Avenida del Talgo 100-103 - 3ª Planta
28023 Madrid
Tfno.: 91 581 27 34 - Extension interna: 412734<https://webdialer/WaitRealizarLlamadaFirma.aspx?date=201203071623553351&msgtype=2&ndest=412734&timer=5000&language=ES&css=default/style&hash=22dcf094f3d1136f55ea7538bf3602e2>
Movil: 618333559
jgarci12-Yu+yOSpmLcTQT0dZR+***@public.gmane.org<mailto:jgarci12-Yu+yOSpmLcTQT0dZR+***@public.gmane.org>

[cid:image001.jpg-***@public.gmane.org]




To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES
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

[Vogtmann, Wallace B]

Per the manual (v7)
http://pic.dhe.ibm.com/infocenter/wmqv7/v7r0m0/topic/com.ibm.mq.csqsaw.doc/za12720_.htm

Reinitializing a queue manager
If the queue manager has terminated abnormally you might not be able to restart it. This could be because your page sets or logs have been lost, truncated, or corrupted. If this has happened, you might have to reinitialize the queue manager (perform a cold start).

Attention
You should only perform a cold start if you cannot restart the queue manager any other way. Performing a cold start enables you to recover your queue manager and your object definitions; you will not be able to recover your message data. Check that none of the other restart scenarios described in this chapter will work for you before you do this.

When you have restarted, all your WebSphere® MQ objects are defined and available for use, but there is no message data.

From: MQSeries List [mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org] On Behalf Of Garcia Juanino, Jorge
Sent: Monday, September 15, 2014 6:24 AM
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org
Subject: MQ start in disaster recovery scenario

Hello:

It's my first post in this fórum. Our experience in MQ z/OS is low and we have a lot of questions about the MQ manage.
The first is about the recover process in a disaster recovery scenario with high activity in channels and queues. In our test scenario when we replicated the MQ devices to a disaster recovery site and there was a high activity, the manager start in a disaster recovery lpar failed with a system abend (we don't remember the code) about consistency of RBA . The workaround was to replicate device in a time with a low activity. In this situation the manager start always works fine.
My question is about a real disaster recovery situation. The channels and queues are with a lot of message in fly. In this scenario we suppose that it's impossible support the messages consistency in MQ channels and queues and you must execute a MQ cold start. Our question is, what's the way to do a MQ cold start? Define a new BSDS, LOG and PSID? Only one of them? Start the manager with a new parm?

Regards

Jorge Garcia Juanino
Gerente sistemas z/OS
ACTP - DIAC - Operación y Soporte EMEA
MAPFRE
Avenida del Talgo 100-103 - 3ª Planta
28023 Madrid
Tfno.: 91 581 27 34 - Extension interna: 412734<https://webdialer/WaitRealizarLlamadaFirma.aspx?date=201203071623553351&msgtype=2&ndest=412734&timer=5000&language=ES&css=default/style&hash=22dcf094f3d1136f55ea7538bf3602e2>
Movil: 618333559
jgarci12-Yu+yOSpmLcTQT0dZR+***@public.gmane.org<mailto:jgarci12-Yu+yOSpmLcTQT0dZR+***@public.gmane.org>

[cid:image001.jpg-***@public.gmane.org]




________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES
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

[Paul S Dennis]

I am slightly concerned that you had issues with your DR testing. It is
perfectly possible to start a queue manager when executing a DR test, even
when the queue manager has been under load. I think it would probably be
worth revisiting this again, to see if you can identify why it didn't work
in your situation. On thing to not is that you should be replicating your
logs, BSDS and pagesets all in the same consistency group. You will run
into difficulties if this isn't the case. Of course, depending on what
other MQ stuff you have going on in your network, there might be a slight
mismatch between your recovered QMGRs at the DR site, and the rest of your
MQ network. So there is a potential for duplication/lost messages,
depending on your exact configuration, and what is being failed over.
However, it should be possible to bring up the QMGR without requiring a
cold start.


Thanks
Paul


Paul Dennis
WebSphere MQ for z/OS Development




From: "Garcia Juanino, Jorge" <***@MAPFRE.COM>
To: ***@LISTSERV.MEDUNIWIEN.AC.AT,
Date: 15/09/2014 12:48
Subject: MQ start in disaster recovery scenario
Sent by: MQSeries List <***@LISTSERV.MEDUNIWIEN.AC.AT>



Hello:

It’s my first post in this fórum. Our experience in MQ z/OS is low and we
have a lot of questions about the MQ manage.
The first is about the recover process in a disaster recovery scenario
with high activity in channels and queues. In our test scenario when we
replicated the MQ devices to a disaster recovery site and there was a high
activity, the manager start in a disaster recovery lpar failed with a
system abend (we don’t remember the code) about consistency of RBA . The
workaround was to replicate device in a time with a low activity. In this
situation the manager start always works fine.
My question is about a real disaster recovery situation. The channels and
queues are with a lot of message in fly. In this scenario we suppose that
it’s impossible support the messages consistency in MQ channels and queues
and you must execute a MQ cold start. Our question is, what’s the way to
do a MQ cold start? Define a new BSDS, LOG and PSID? Only one of them?
Start the manager with a new parm?

Regards

Jorge Garcia Juanino
Gerente sistemas z/OS
ACTP – DIAC – Operación y Soporte EMEA
MAPFRE
Avenida del Talgo 100-103 – 3ª Planta
28023 Madrid
Tfno.: 91 581 27 34 – Extension interna: 412734
Movil: 618333559
***@mapfre.com







List Archive - Manage Your List Settings - Unsubscribe
Instructions for managing your mailing list subscription are provided in
the Listserv General Users Guide available at http://www.lsoft.com

Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU


To unsubscribe, write to ***@LISTSERV.MEDUNIWIEN.AC.AT and,
in the message body (not the subject), write: SIGNOFF MQSERIES
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

[Garcia Juanino, Jorge]

Thanks Paul. We'll try to execute the same DR test. If the manager doesn't start again we'll send you the abend. Of course, we'll replicate the logs, bsds an pagetes together in the same group.

Regards


Date: Mon, 15 Sep 2014 22:01:52 +0100
From: Paul S Dennis <DENNISPS-E4/***@public.gmane.org<mailto:DENNISPS-E4/***@public.gmane.org>>
Subject: Re: MQ start in disaster recovery scenario

I am slightly concerned that you had issues with your DR testing. It is perfectly possible to start a queue manager when executing a DR test, even when the queue manager has been under load. I think it would probably be worth revisiting this again, to see if you can identify why it didn't work in your situation. On thing to not is that you should be replicating your logs, BSDS and pagesets all in the same consistency group. You will run into difficulties if this isn't the case. Of course, depending on what other MQ stuff you have going on in your network, there might be a slight mismatch between your recovered QMGRs at the DR site, and the rest of your MQ network. So there is a potential for duplication/lost messages, depending on your exact configuration, and what is being failed over.
However, it should be possible to bring up the QMGR without requiring a cold start.


Thanks
Paul


Paul Dennis
WebSphere MQ for z/OS Development




From: "Garcia Juanino, Jorge" <jgarci12-***@public.gmane.org<mailto:***@MAPFRE.COM>>
To: MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:MQSERIES-0lvw86wZMd9k/***@public.gmane.orgIEN.AC.AT>,
Date: 15/09/2014 12:48
Subject: MQ start in disaster recovery scenario
Sent by: MQSeries List <MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org<mailto:MQSERIES-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org>>



Hello:

It's my first post in this fórum. Our experience in MQ z/OS is low and we have a lot of questions about the MQ manage.
The first is about the recover process in a disaster recovery scenario with high activity in channels and queues. In our test scenario when we replicated the MQ devices to a disaster recovery site and there was a high activity, the manager start in a disaster recovery lpar failed with a system abend (we don't remember the code) about consistency of RBA . The workaround was to replicate device in a time with a low activity. In this situation the manager start always works fine.
My question is about a real disaster recovery situation. The channels and queues are with a lot of message in fly. In this scenario we suppose that it's impossible support the messages consistency in MQ channels and queues and you must execute a MQ cold start. Our question is, what's the way to do a MQ cold start? Define a new BSDS, LOG and PSID? Only one of them?
Start the manager with a new parm?

Regards

Jorge Garcia Juanino
Gerente sistemas z/OS
ACTP - DIAC - Operación y Soporte EMEA
MAPFRE
Avenida del Talgo 100-103 - 3ª Planta
28023 Madrid
Tfno.: 91 581 27 34 - Extension interna: 412734
Movil: 618333559
jgarci12-Yu+yOSpmLcTQT0dZR+***@public.gmane.org<mailto:jgarci12-Yu+yOSpmLcTQT0dZR+***@public.gmane.org>


Jorge Garcia Juanino
Gerente sistemas z/OS
ACTP - DIAC - Operación y Soporte EMEA
MAPFRE
Avenida del Talgo 100-103 - 3ª Planta
28023 Madrid
Tfno.: 91 581 27 34 - Extension interna: 412734<https://webdialer/WaitRealizarLlamadaFirma.aspx?date=201203071623553351&msgtype=2&ndest=412734&timer=5000&language=ES&css=default/style&hash=22dcf094f3d1136f55ea7538bf3602e2>
Movil: 618333559
jgarci12-Yu+yOSpmLcTQT0dZR+***@public.gmane.org<mailto:jgarci12-Yu+yOSpmLcTQT0dZR+***@public.gmane.org>

[cid:image001.jpg-***@public.gmane.org]




To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES
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

[Glenn Baddeley]

Post by Garcia Juanino, Jorge
Of course, depending on what other MQ stuff you have going on in your network, there might be a slight
mismatch between your recovered QMGRs at the DR site, and the rest of your MQ network. So there is a
potential for duplication/lost messages, depending on your exact configuration, and what is being failed over.

Some MQ DR plans stipulate that queue managers at DR sites will be restarted and handed over for app usage with empty application queues and transmission queues. Reconciliation of missing or duplicate messages is the responsiblity of the applications, to resend messages or eliminate duplicates. Restarting a queue manager with a bunch of queued messages in an unknown application processing state may only serve to muddy the waters. This is not such an issue with DR queue managers that are synchronous or near-synchronous replicated to the queue managers.

Cheers,
Glenn Baddeley
Coles Supermarkets Australia Pty. Ltd.

To unsubscribe, write to LISTSERV-0lvw86wZMd9k/bWDasg6f+***@public.gmane.org and,
in the message body (not the subject), write: SIGNOFF MQSERIES

[Wisdom, Stephen (Sean Wisdom)]

All,
I’ll offer my little tips garnered at various shops I’ve worked on/for.
Tune your PROD qmgrs to checkpoint around every 20 minutes. On Dev environments I’ve found that
Forcing this via automation (3 times a day IIRC) the only reliable method due to their nature of use.
I’ll echo the consistency group settings mentioned. Been there, done that etc.
You should always have a checkpoint setting job lying around, as you may need (and I’ve hit this)
To specify a checkpoint restart point – if your Qmgr happened to have been “snapshotted”
When it is performing an archive log. I would also recommend you maintain a recovery options
Dataset (including all JCL members required for a COLD Start ) for your Qmgr’s depending on
your shop’s setup.


HTH
Sean Wisdom
HPES MQ


From: MQSeries List [mailto:***@LISTSERV.MEDUNIWIEN.AC.AT] On Behalf Of Paul S Dennis
Sent: Tuesday, 16 September 2014 7:02 AM
To: ***@LISTSERV.MEDUNIWIEN.AC.AT<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT>
Subject: Re: MQ start in disaster recovery scenario

I am slightly concerned that you had issues with your DR testing. It is perfectly possible to start a queue manager when executing a DR test, even when the queue manager has been under load. I think it would probably be worth revisiting this again, to see if you can identify why it didn't work in your situation. On thing to not is that you should be replicating your logs, BSDS and pagesets all in the same consistency group. You will run into difficulties if this isn't the case. Of course, depending on what other MQ stuff you have going on in your network, there might be a slight mismatch between your recovered QMGRs at the DR site, and the rest of your MQ network. So there is a potential for duplication/lost messages, depending on your exact configuration, and what is being failed over. However, it should be possible to bring up the QMGR without requiring a cold start.


Thanks
Paul


Paul Dennis
WebSphere MQ for z/OS Development




From: "Garcia Juanino, Jorge" <***@MAPFRE.COM<mailto:***@MAPFRE.COM>>
To: ***@LISTSERV.MEDUNIWIEN.AC.AT<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT>,
Date: 15/09/2014 12:48
Subject: MQ start in disaster recovery scenario
Sent by: MQSeries List <***@LISTSERV.MEDUNIWIEN.AC.AT<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT>>
________________________________



Hello:

It’s my first post in this fórum. Our experience in MQ z/OS is low and we have a lot of questions about the MQ manage.
The first is about the recover process in a disaster recovery scenario with high activity in channels and queues. In our test scenario when we replicated the MQ devices to a disaster recovery site and there was a high activity, the manager start in a disaster recovery lpar failed with a system abend (we don’t remember the code) about consistency of RBA . The workaround was to replicate device in a time with a low activity. In this situation the manager start always works fine.
My question is about a real disaster recovery situation. The channels and queues are with a lot of message in fly. In this scenario we suppose that it’s impossible support the messages consistency in MQ channels and queues and you must execute a MQ cold start. Our question is, what’s the way to do a MQ cold start? Define a new BSDS, LOG and PSID? Only one of them? Start the manager with a new parm?

Regards

Jorge Garcia Juanino
Gerente sistemas z/OS
ACTP – DIAC – Operación y Soporte EMEA
MAPFRE
Avenida del Talgo 100-103 – 3ª Planta
28023 Madrid
Tfno.: 91 581 27 34 – Extension interna: 412734<https://webdialer/WaitRealizarLlamadaFirma.aspx?date=201203071623553351&msgtype=2&ndest=412734&timer=5000&language=ES&css=default/style&hash=22dcf094f3d1136f55ea7538bf3602e2>
Movil: 618333559
***@mapfre.com<mailto:***@mapfre.com>





________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>


Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
________________________________
List Archive<http://listserv.meduniwien.ac.at/archives/mqser-l.html> - Manage Your List Settings<http://listserv.meduniwien.ac.at/cgi-bin/wa?SUBED1=mqser-l&A=1> - Unsubscribe<mailto:***@LISTSERV.MEDUNIWIEN.AC.AT?subject=Unsubscribe&BODY=signoff%20mqseries>

Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com<http://www.lsoft.com/resources/manuals.asp>

To unsubscribe, write to ***@LISTSERV.MEDUNIWIEN.AC.AT and,
in the message body (not the subject), write: SIGNOFF MQSERIES
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