Channel control function / Stopping and quiescing channels / Restarting stopped channels z/OS - Middleware News
Channel control function / Stopping and quiescing channels / Restarting stopped channels z/OS - Middleware News
Channel Control Function
Stopping and quiescing channels
==========================
Message channels are designed to be long-running connections between queue managers with orderly termination controlled only by the disconnect interval channel attribute. This mechanism works well unless the operator needs to terminate the channel before the disconnect time interval expires. This can occur in the following situations:
• System quiesce
• Resource conservation
• Unilateral action at one end of a channel
In this case, an operator command is provided to allow you to stop the channel. The command provided varies by platform, as follows:
For z/OS without CICS:
The STOP CHANNEL MQSC command or the Stop a channel panel
For z/OS using CICS:
The Stop option on the Message Channel List panel
For OS/2, Windows systems, Compaq OpenVMS Alpha, Compaq NonStop Kernel, and UNIX systems:
The STOP CHANNEL MQSC or PCF command
For iSeries:
ENDMQMCHL or the END option on the WRKMQMCHL panel
For VSE/ESA:
The CLOSE command from the MQMMSC panel or MQCL transaction closes (rather than stops) the channel.
There are three options for stopping channels using these commands:
QUIESCE
The QUIESCE option attempts to end the current batch of messages before stopping the channel.
FORCE
The FORCE option attempts to stop the channel immediately and may require the channel to resynchronize when it restarts because the channel may be left in doubt.
TERMINATE
The TERMINATE option attemps to stop the channel immediately, and terminates the channel's thread or process.
Note that all of these options leave the channel in a STOPPED state, requiring operator intervention to restart it.
Stopping the channel at the sending end is quite effective but does require operator intervention to restart. At the receiving end of the channel, things are much more difficult because the MCA is waiting for data from the sending side, and there is no way to initiate an orderly termination of the channel from the receiving side; the stop command is pending until the MCA returns from its wait for data.
Consequently there are three recommended ways of using channels, depending upon the operational characteristics required:
• If you want your channels to be long running, you should note that there can be orderly termination only from the sending end. When channels are interrupted, that is, stopped, operator intervention (a START CHANNEL command) is required in order to restart them.
• If you want your channels to be active only when there are messages for them to transmit, you should set the disconnect interval to a fairly low value. Note that the default setting is quite high and so is not recommended for channels where this level of control is required. Because it is difficult to interrupt the receiving channel, the most economical option is to have the channel automatically disconnect and reconnect as the workload demands. For most channels, the appropriate setting of the disconnect interval can be established heuristically.
• For WebSphere MQ for AIX, iSeries, HP-UX, Linux, Solaris, Windows systems, and z/OS without CICS, and MQSeries V5.1 for OS/2 Warp, you can use the heartbeat-interval attribute to cause the sending MCA to send a heartbeat flow to the receiving MCA during periods in which it has no messages to send. This releases the receiving MCA from its wait state and gives it an opportunity to quiesce the channel without waiting for the disconnect interval to expire. Give the heartbeat interval a lower value than the value of the disconnect interval.
Notes:
1. You are advised to set the disconnect interval to a low value, or to use heartbeats, for server channels. This is to allow for the case where the requester channel ends abnormally (for example, because the channel was canceled) when there are no messages for the server channel to send. In this case, the server does not detect that the requester has ended (it will only do this the next time it tries to send a message to the requester). While the server is still running, it holds the transmission queue open for exclusive input in order to get any more messages that arrive on the queue. If an attempt is made to restart the channel from the requester, the start request receives an error because the server still has the transmission queue open for exclusive input. It is necessary to stop the server channel, and then restart the channel from the requester again.
2. On WebSphere MQ for AIX, iSeries, HP-UX, Linux, Solaris, Windows systems, and z/OS without CICS, and MQSeries V5.1 for Compaq Tru64 UNIX, and OS/2 Warp, server-connection channels can also be stopped like receiver channels.
Restarting stopped channels
======================
When a channel goes into STOPPED state (either because you have stopped the channel manually using one of the methods given in Stopping and quiescing channels, or because of a channel error) you have to restart the channel manually.
To do this, issue one of the following commands:
For WebSphere MQ for z/OS without CICS:
The START CHANNEL MQSC command or the Start a channel panel
For WebSphere MQ for z/OS using CICS:
The Start option on the Message Channel List panel
For WebSphere MQ for UNIX systems and Windows systems, and MQSeries for OS/2 Warp, Compaq OpenVMS Alpha, Compaq NonStop Kernel, :
The START CHANNEL MQSC or PCF command
For WebSphere MQ for iSeries:
The START command on the WRKMQMCHL panel, the STRMQMCHL command, or the START CHANNEL MQSC or PCF command
For MQSeries for VSE/ESA:
The OPEN command from the MQMMSC panel or MQCL transaction opens (rather than restarts) the channel.
For sender or server channels, when the channel entered the STOPPED state, the associated transmission queue was set to GET(DISABLED) and triggering was set off. When the start request is received, these attributes are reset automatically. On WebSphere MQ for AIX, iSeries, HP-UX, Linux, Solaris, Windows systems, and z/OS without CICS, and MQSeries V5.1 for OS/2 Warp, if the channel initiator or queue manager stops while a channel is in RETRYING or STOPPED status, the channel status is remembered when the channel initiator or queue manager is restarted. On other platforms, if the channel initiator or queue manager is restarted the status is lost and you have to alter the queue attributes manually to re-enable triggering of the channel.
Note:
If you are using CICS for distributed queuing on z/OS, these queue attributes are not reset automatically; you always have to alter them manually when you restart a channel.
In-doubt channels
=============
An in-doubt channel is a channel that is in doubt with a remote channel about which messages have been sent and received. Note the distinction between this and a queue manager being in doubt about which messages should be committed to a queue.
You can reduce the opportunity for a channel to be placed in doubt by using the Batch Heartbeat channel parameter (BATCHHB). When a value for this parameter is specified, a sender channel checks that the remote channel is still active before taking any further action. If no response is received the receiver channel is considered to be no longer active. The messages can be rolled-back, and re-routed, and the sender-channel is not put in doubt. This reduces the time when the channel could be placed in doubt to the period between the sender channel verifying that the receiver channel is still active, and verifying that the receiver channel has received the sent messages. See Chapter 6, Channel attributes for more information on the batch heartbeat parameter.
In-doubt channel problems are usually resolved automatically. Even when communication is lost, and a channel is placed in doubt with a message batch at the sender whose receipt status is unknown, the situation is resolved when communication is re-established. Sequence number and LUWID records are kept for this purpose. The channel is in doubt until LUWID information has been exchanged, and only one batch of messages can be in doubt for the channel.
You can, when necessary, resynchronize the channel manually. The term manual includes use of operators or programs that contain WebSphere MQ system management commands. The manual resynchronization process works as follows. This description uses MQSC commands, but you can also use the PCF equivalents.
1. Use the DISPLAY CHSTATUS command to find the last-committed logical unit of work ID (LUWID) for each side of the channel. Do this using the following commands:
o For the in-doubt side of the channel:
o DISPLAY CHSTATUS(name) SAVED CURLUWID
You can use the CONNAME and XMITQ parameters to further identify the channel.
o For the receiving side of the channel:
o DISPLAY CHSTATUS(name) SAVED LSTLUWID
You can use the CONNAME parameter to further identify the channel.
2. The commands are different because only the sending side of the channel can be in doubt. The receiving side is never in doubt.
3. On WebSphere MQ for iSeries, the DISPLAY CHSTATUS command can be executed from a file using the STRMQMMQSC command or the Work with MQM Channel Status CL command, WRKMQMCHST
4. If the two LUWIDs are the same, the receiving side has committed the unit of work that the sender considers to be in doubt. The sending side can now remove the in-doubt messages from the transmission queue and re-enable it. This is done with the following channel RESOLVE command:
5. RESOLVE CHANNEL(name) ACTION(COMMIT)
6. If the two LUWIDs are different, the receiving side has not committed the unit of work that the sender considers to be in doubt. The sending side needs to retain the in-doubt messages on the transmission queue and re-send them. This is done with the following channel RESOLVE command:
7. RESOLVE CHANNEL(name) ACTION(BACKOUT)
On WebSphere MQ for iSeries, you can use the Resolve MQM Channel command, RSVMQMCHL.
Once this process is complete the channel is no longer in doubt. The transmission queue can now be used by another channel, if required.
Problem determination
================
There are two distinct aspects to problem determination:
• Problems discovered when a command is being submitted
• Problems discovered during operation of the channels
Command validation
Commands and panel data must be free from errors before they are accepted for processing. Any errors found by the validation are immediately notified to the user by error messages.
Problem diagnosis begins with the interpretation of these error messages and taking the recommended corrective action.
Processing problems
Problems found during normal operation of the channels are notified to the system console or the system log. Problem diagnosis begins with the collection of all relevant information from the log, and continues with analysis to identify the problem.
Confirmation and error messages are returned to the terminal that initiated the commands, when possible.
Channel Control Function
Stopping and quiescing channels
==========================
Message channels are designed to be long-running connections between queue managers with orderly termination controlled only by the disconnect interval channel attribute. This mechanism works well unless the operator needs to terminate the channel before the disconnect time interval expires. This can occur in the following situations:
• System quiesce
• Resource conservation
• Unilateral action at one end of a channel
In this case, an operator command is provided to allow you to stop the channel. The command provided varies by platform, as follows:
For z/OS without CICS:
The STOP CHANNEL MQSC command or the Stop a channel panel
For z/OS using CICS:
The Stop option on the Message Channel List panel
For OS/2, Windows systems, Compaq OpenVMS Alpha, Compaq NonStop Kernel, and UNIX systems:
The STOP CHANNEL MQSC or PCF command
For iSeries:
ENDMQMCHL or the END option on the WRKMQMCHL panel
For VSE/ESA:
The CLOSE command from the MQMMSC panel or MQCL transaction closes (rather than stops) the channel.
There are three options for stopping channels using these commands:
QUIESCE
The QUIESCE option attempts to end the current batch of messages before stopping the channel.
FORCE
The FORCE option attempts to stop the channel immediately and may require the channel to resynchronize when it restarts because the channel may be left in doubt.
TERMINATE
The TERMINATE option attemps to stop the channel immediately, and terminates the channel's thread or process.
Note that all of these options leave the channel in a STOPPED state, requiring operator intervention to restart it.
Stopping the channel at the sending end is quite effective but does require operator intervention to restart. At the receiving end of the channel, things are much more difficult because the MCA is waiting for data from the sending side, and there is no way to initiate an orderly termination of the channel from the receiving side; the stop command is pending until the MCA returns from its wait for data.
Consequently there are three recommended ways of using channels, depending upon the operational characteristics required:
• If you want your channels to be long running, you should note that there can be orderly termination only from the sending end. When channels are interrupted, that is, stopped, operator intervention (a START CHANNEL command) is required in order to restart them.
• If you want your channels to be active only when there are messages for them to transmit, you should set the disconnect interval to a fairly low value. Note that the default setting is quite high and so is not recommended for channels where this level of control is required. Because it is difficult to interrupt the receiving channel, the most economical option is to have the channel automatically disconnect and reconnect as the workload demands. For most channels, the appropriate setting of the disconnect interval can be established heuristically.
• For WebSphere MQ for AIX, iSeries, HP-UX, Linux, Solaris, Windows systems, and z/OS without CICS, and MQSeries V5.1 for OS/2 Warp, you can use the heartbeat-interval attribute to cause the sending MCA to send a heartbeat flow to the receiving MCA during periods in which it has no messages to send. This releases the receiving MCA from its wait state and gives it an opportunity to quiesce the channel without waiting for the disconnect interval to expire. Give the heartbeat interval a lower value than the value of the disconnect interval.
Notes:
1. You are advised to set the disconnect interval to a low value, or to use heartbeats, for server channels. This is to allow for the case where the requester channel ends abnormally (for example, because the channel was canceled) when there are no messages for the server channel to send. In this case, the server does not detect that the requester has ended (it will only do this the next time it tries to send a message to the requester). While the server is still running, it holds the transmission queue open for exclusive input in order to get any more messages that arrive on the queue. If an attempt is made to restart the channel from the requester, the start request receives an error because the server still has the transmission queue open for exclusive input. It is necessary to stop the server channel, and then restart the channel from the requester again.
2. On WebSphere MQ for AIX, iSeries, HP-UX, Linux, Solaris, Windows systems, and z/OS without CICS, and MQSeries V5.1 for Compaq Tru64 UNIX, and OS/2 Warp, server-connection channels can also be stopped like receiver channels.
Restarting stopped channels
======================
When a channel goes into STOPPED state (either because you have stopped the channel manually using one of the methods given in Stopping and quiescing channels, or because of a channel error) you have to restart the channel manually.
To do this, issue one of the following commands:
For WebSphere MQ for z/OS without CICS:
The START CHANNEL MQSC command or the Start a channel panel
For WebSphere MQ for z/OS using CICS:
The Start option on the Message Channel List panel
For WebSphere MQ for UNIX systems and Windows systems, and MQSeries for OS/2 Warp, Compaq OpenVMS Alpha, Compaq NonStop Kernel, :
The START CHANNEL MQSC or PCF command
For WebSphere MQ for iSeries:
The START command on the WRKMQMCHL panel, the STRMQMCHL command, or the START CHANNEL MQSC or PCF command
For MQSeries for VSE/ESA:
The OPEN command from the MQMMSC panel or MQCL transaction opens (rather than restarts) the channel.
For sender or server channels, when the channel entered the STOPPED state, the associated transmission queue was set to GET(DISABLED) and triggering was set off. When the start request is received, these attributes are reset automatically. On WebSphere MQ for AIX, iSeries, HP-UX, Linux, Solaris, Windows systems, and z/OS without CICS, and MQSeries V5.1 for OS/2 Warp, if the channel initiator or queue manager stops while a channel is in RETRYING or STOPPED status, the channel status is remembered when the channel initiator or queue manager is restarted. On other platforms, if the channel initiator or queue manager is restarted the status is lost and you have to alter the queue attributes manually to re-enable triggering of the channel.
Note:
If you are using CICS for distributed queuing on z/OS, these queue attributes are not reset automatically; you always have to alter them manually when you restart a channel.
In-doubt channels
=============
An in-doubt channel is a channel that is in doubt with a remote channel about which messages have been sent and received. Note the distinction between this and a queue manager being in doubt about which messages should be committed to a queue.
You can reduce the opportunity for a channel to be placed in doubt by using the Batch Heartbeat channel parameter (BATCHHB). When a value for this parameter is specified, a sender channel checks that the remote channel is still active before taking any further action. If no response is received the receiver channel is considered to be no longer active. The messages can be rolled-back, and re-routed, and the sender-channel is not put in doubt. This reduces the time when the channel could be placed in doubt to the period between the sender channel verifying that the receiver channel is still active, and verifying that the receiver channel has received the sent messages. See Chapter 6, Channel attributes for more information on the batch heartbeat parameter.
In-doubt channel problems are usually resolved automatically. Even when communication is lost, and a channel is placed in doubt with a message batch at the sender whose receipt status is unknown, the situation is resolved when communication is re-established. Sequence number and LUWID records are kept for this purpose. The channel is in doubt until LUWID information has been exchanged, and only one batch of messages can be in doubt for the channel.
You can, when necessary, resynchronize the channel manually. The term manual includes use of operators or programs that contain WebSphere MQ system management commands. The manual resynchronization process works as follows. This description uses MQSC commands, but you can also use the PCF equivalents.
1. Use the DISPLAY CHSTATUS command to find the last-committed logical unit of work ID (LUWID) for each side of the channel. Do this using the following commands:
o For the in-doubt side of the channel:
o DISPLAY CHSTATUS(name) SAVED CURLUWID
You can use the CONNAME and XMITQ parameters to further identify the channel.
o For the receiving side of the channel:
o DISPLAY CHSTATUS(name) SAVED LSTLUWID
You can use the CONNAME parameter to further identify the channel.
2. The commands are different because only the sending side of the channel can be in doubt. The receiving side is never in doubt.
3. On WebSphere MQ for iSeries, the DISPLAY CHSTATUS command can be executed from a file using the STRMQMMQSC command or the Work with MQM Channel Status CL command, WRKMQMCHST
4. If the two LUWIDs are the same, the receiving side has committed the unit of work that the sender considers to be in doubt. The sending side can now remove the in-doubt messages from the transmission queue and re-enable it. This is done with the following channel RESOLVE command:
5. RESOLVE CHANNEL(name) ACTION(COMMIT)
6. If the two LUWIDs are different, the receiving side has not committed the unit of work that the sender considers to be in doubt. The sending side needs to retain the in-doubt messages on the transmission queue and re-send them. This is done with the following channel RESOLVE command:
7. RESOLVE CHANNEL(name) ACTION(BACKOUT)
On WebSphere MQ for iSeries, you can use the Resolve MQM Channel command, RSVMQMCHL.
Once this process is complete the channel is no longer in doubt. The transmission queue can now be used by another channel, if required.
Problem determination
================
There are two distinct aspects to problem determination:
• Problems discovered when a command is being submitted
• Problems discovered during operation of the channels
Command validation
Commands and panel data must be free from errors before they are accepted for processing. Any errors found by the validation are immediately notified to the user by error messages.
Problem diagnosis begins with the interpretation of these error messages and taking the recommended corrective action.
Processing problems
Problems found during normal operation of the channels are notified to the system console or the system log. Problem diagnosis begins with the collection of all relevant information from the log, and continues with analysis to identify the problem.
Confirmation and error messages are returned to the terminal that initiated the commands, when possible.
Comments
Post a Comment