System interruptions

 

Your application might be unaware of any interruption if the queue manager to which it is connected has to recover from a system failure. However, you must design your application to ensure that your data is not lost if such an interruption occurs.

The methods that we can use to make sure that your data remains consistent depends on the platform on which your queue manager is running:

z/OS

In the CICS and IMS™ environments, we can make MQPUT and MQGET calls within units of work that are managed by CICS or IMS. In the batch environment, we can make MQPUT and MQGET calls in the same way, but declare syncpoints using:

i5/OS

We can make your MQPUT and MQGET calls within global units of work that are managed by i5/OS commitment control. We can declare syncpoints by using the native i5/OS COMMIT and ROLLBACK commands or the language-specific commands. Local units of work are managed by WebSphere MQ using the MQCMIT and MQBACK calls.

UNIX systems and Windows systems

In these environments, we can make your MQPUT and MQGET calls in the usual way, but declare syncpoints by using the MQCMIT and MQBACK calls (see Committing and backing out units of work). In the CICS environment, MQCMIT and MQBACK commands are disabled, because we can make your MQPUT and MQGET calls within units of work that are managed by CICS.

Use persistent messages for carrying all data that we cannot afford to lose. Persistent messages are reinstated on queues if the queue manager has to recover from a failure. With WebSphere MQ on UNIX systems and WebSphere MQ for Windows, an MQGET or MQPUT call within your application will fail at the point of filling all the log files, with the message MQRC_RESOURCE_PROBLEM. For more information on log files on AIX, HP-UX, Linux, Solaris, and Windows systems, see the WebSphere MQ System Administration Guide; for z/OS™ see the WebSphere MQ for z/OS Concepts and Planning Guide.

If the queue manager is stopped by an operator while an application is running, the quiesce option is usually used. The queue manager enters a quiescing state in which applications can continue to do work, but they must terminate as soon as convenient. Small, quick applications can probably ignore the quiescing state and continue until they terminate as normal. Longer running applications, or ones that wait for messages to arrive, should use the fail if quiescing option when they use the MQOPEN, MQPUT, MQPUT1, and MQGET calls. These options mean that the calls fail when the queue manager quiesces, but the application might still have time to terminate cleanly by issuing calls that ignore the quiescing state. Such applications could also commit, or back out, changes that they have made, and then terminate.

If the queue manager is forced to stop (that is, stop without quiescing), applications will receive the MQRC_CONNECTION_BROKEN reason code when they make MQI calls. At this point, exit the application or, alternatively, on WebSphere MQ for iSeries™, WebSphere MQ on UNIX systems, and WebSphere MQ for Windows, issue an MQDISC call.

 

Parent topic:

Locally determined errors


fg11260_