MQ

 View Only

 The remote channel is not currently available

RADEK VANĚK's profile image
RADEK VANĚK posted Thu June 05, 2025 06:46 AM

Hello, 

I am facing the following issue after the migration to 9.4 on the mainframe:

There are various sender/receiver channel established from distributed side to the mainframe and these situation appeared often:

1) MAINFRAME side

+CSQX208E +CDC1 CSQXRESP Error receiving data,
     channel x.y
     connection <conn>
     TRPTYPE=TCP RC=00000460 (ECONNABORTED) reason=769E0291

+CSQX599E +CDC1 CSQXRESP Channel x.y ended abnormally, connection <conn>

+CSQX475I +CDC1 CSQXRESP Channel x.y adopted, connection <conn> 

+CSQX209E +CDC1 CSQXRESP Connection unexpectedly terminated,
     channel x.y
     connection <conn>
     TRPTYPE=TCP RC=00000000

2) DISTRIBUTED side shows the error message: The remote channel 'x.y' on host 'mainframe ip(port)' is not currently available.

The problem is that at the moment of this error the mainframe part (receiver in that case) if this connection is still in RUN status. Seems like the mainframe receiver remained orphaned and cannot be reconnected. To solve this issue it is usually necessary to restart CHIN on both sides, maybe stop/start channel from sender side could be also enough but for sure manual intervention is needed.

I do not believe the issue could be caused by lack of resource on the mainframe side as we are running CHIN address space with REGION=0 (no limit). What is look strange to me is the CSQX475I message .. 

Could you, please, help me to understand this issue and how to prevent it?

Thank you!

Best regards,
Radek

P.S.> Additionally, there is also a big number of CSQX068I messages saying that 'CHIN has scavenged space from transmission buffers' .. could this be in connection to the above mentioned issue, please? 

Morag Hughson's profile image
Morag Hughson IBM Champion posted Thu June 05, 2025 07:59 AM

There is no need to restart the CHIN on both sides to resolved the channel still being in RUN status, simply issue the following command on the RCVR.

STOP CHANNEL('x.y')MODE(FORCE) STATUS(INACTIVE)

This will leave it in a status ready to accept a new connection.

However, I don't believe this is the root of your problem because if a channel is in RUN status and is orphaned, and the same partner reconnects, the CHIN will notice, will end the old one and Adopt the new one, assuming you have the CHIN configured to allow this. When it happens you see message CSQX475I as you do, suggesting adopting is on and happening in your setup.

It seems that connectivity errors are causing issues for you. Are there any reports in firewalls suggesting connections have been dropped?

CSQX068I is an informational message (hence the I) but it is only output when your CHINIT is at 75% virtual storage used, so certainly there is a lot in use. However, in itself it does not indicate a problem. How much storage is your CHIN using?

You mention REGION=0 but that is only no limit on 31-bit storage. Do you also have a MEMLIMIT statement? Suggested value 2G - see https://www.ibm.com/docs/en/ibm-mq/9.4.x?topic=configuration-channel-initiator-storage-from-mq-940

Cheers,
Morag

RADEK VANĚK's profile image
RADEK VANĚK posted Thu June 05, 2025 08:17 AM

Hello Morag, good morning!

First of all thank you for your reply even if it is still not clear to me what could solve this issue.

One of the possible reason mentioned in message explanation is a lack of resources on the mainframe side. The message CSQX068I and their often occurrences (approx. 4-10 per hour) looks strange to. In fact we do not use MEMLIMIT for CHIN STC but according to the regular "storage monitoring" message CSQX004I (every hour in the output) it does not seems to be an issue:

+CSQX004I +CDC1 CSQXSPRM Channel initiator storage usage: local  876
 storage: used 25MB, free 1614MB: above bar: used 227MB, free >10GB 

It seems like we have 2 GB available .. 

Unfortunately, I do not have any information from the firewall. 

Is there anything else to be checked from our (mainframe or distributed) ends to move forward with the RCA?

Thank you so much!

Best regards,
Radek

Morag Hughson's profile image
Morag Hughson IBM Champion posted Thu June 05, 2025 07:40 PM

Did you issue the command I provided? Is the problem still occurring?

I agree that it does not appear to be a storage shortage problem.

I encourage you to discover the reason for TCP/IP failures - talk to your network and firewall people to see what they say.

Cheers,
Morag

Francois Brandelik's profile image
Francois Brandelik IBM Champion posted Fri June 06, 2025 05:21 AM

Have you considered looking on the MF at your tcp stanza in the qm.ini

Do you have a keep alive stanza there?

Do you have a disconnect interval on the corresponding (distributed) sender.Do you have a KEEP ALIVE entry in the TCP Stanza on the sender side?

Did you set a heartbeat interval on the sender channel that is less than your firewall idle timeout?

Related Content