If there were any kind of TCP/IP error at all, then the MQ Client code would write something in the AMQERR01.LOG file on the client machine. I am frankly astounded that a machine running anything with network connectivity can go over six months without anything to report in the AMQERR01.LOG file. Are you just going by the timestamp of the file, or have you actually viewed the contents of the file to see if there are any errors written inside?
Assuming that there really are no errors, then really to go any further with this, we must understand your earlier comment. To repeat what I asked earlier, I am interested to learn more about what you say at the end of the earlier post: "The client reports that restarting our AG channel, whose IP address is 10.200.1.41, causes them to lose connection." What *EXACTLY* do they mean by "restarting our channel"? Who is doing this "restarting", upon what machine are they doing it, and what command do they issue in order to do it? Clearly this is very pertinent to the issue that is being seen, so it would be extremely useful to understand what they mean by this.
Original Message:
Sent: Fri January 30, 2026 09:13 AM
From: Ursula Jimenez Zegarra
Subject: MQ SERVER CONNECTION CHANNEL INACTIVE
Good Morning Morag !!
Thnks, but i dondt see any error in the client machine since last year.
[root@NCCELXICEXSH1 errors]# ls -lstr
total 172
0 -rw-rw-r-- 1 mqm mqm 0 May 17 2023 AMQERR03.LOG
0 -rw-rw-r-- 1 mqm mqm 0 May 17 2023 AMQERR02.LOG
172 -rw-rw-r-- 1 mqm mqm 172288 May 31 2025 AMQERR01.LOG
[root@NCCELXICEXSH1 errors]#
If there were a network infrastructure problem with lost MQ packets, would it be able to show up in the log?
thanks
------------------------------
Ursula Jimenez Zegarra
Original Message:
Sent: Thu January 29, 2026 08:57 PM
From: Morag Hughson
Subject: MQ SERVER CONNECTION CHANNEL INACTIVE
When using the MQ Client (aka a network attached MQ application) there is no requirement for it to be on the same machine as the queue manager - that is the whole purpose of the MQ client.
It is of course more efficient if the application is on the same machine as the queue manager, in which case you can make a local bindings connection and avoid the network altogether.
But IBM MQ offers you the choice. You should run your application wherever you need it to run.
Did you manage to get the client application owner to look in /var/mqm/errors/AMQERR01.LOG on the client machine yet?
Did they tell you the reason code that their application encountered yet?
Cheers,
Morag
------------------------------
Morag Hughson
MQ Technical Education Specialist
MQGem Software Limited
Website: https://www.mqgem.com
Original Message:
Sent: Thu January 29, 2026 08:20 PM
From: Ursula Jimenez Zegarra
Subject: MQ SERVER CONNECTION CHANNEL INACTIVE
Thanks Morgan !!!
We've verified that the machines are on different chassis at the infrastructure level: the MQ and the client MQ where the application is located.
For MQ, do you recommend that everything be on the same machine?
------------------------------
Ursula Jimenez Zegarra
Original Message:
Sent: Tue January 27, 2026 09:20 PM
From: Morag Hughson
Subject: MQ SERVER CONNECTION CHANNEL INACTIVE
Thanks Ursula,
I can immediately learn something useful from this output.
Your application is a 'C' client application - learned from RPRODUCT(MQCC). This means that the error messages written on the client machine will be found in /var/mqm/errors/AMQERR01.LOG file on the client machine (assuming a Linux machine based on the icexsd application name). This is where you should direct your client application owner to look if they have not already looked.
I am interested to learn more about what you say at the end of this post: "The client reports that restarting our AG channel, whose IP address is 10.200.1.41, causes them to lose connection." What *EXACTLY* do they mean by "restarting our channel"? Who is doing this "restarting", upon what machine are they doing it, and what command do they issue in order to do it? Clearly this is very pertinent to the issue that is being seen, so it would be extremely useful to understand what they mean by this.
I have to repeat myself on one point though. You, as the administrator of the SVRCONN end of the channel, *CANNOT* ensure that the channel is always active. This is not within your control. All you can do is ensure that the channel is always available to be active when the client application needs it to be active. It will only be active when the client application makes a connection to the queue manager. In will inactive at all other times. None of the descriptions you have provided so far suggest that there are any problems with the channel becoming active. Instead you appear to have problems with a loss of connectivity during the lifetime of a running channel instance. Let's focus on what the client means by the statement above and see if we can get to the bottom of that.
Cheers,
Morag
------------------------------
Morag Hughson
MQ Technical Education Specialist
MQGem Software Limited
Website: https://www.mqgem.com
Original Message:
Sent: Tue January 27, 2026 05:57 PM
From: Ursula Jimenez Zegarra
Subject: MQ SERVER CONNECTION CHANNEL INACTIVE
Thanks Morgan !!!!
The result is :
dis chstatus(AG.*) all
1 : dis chstatus(AG.*) all
AMQ8417I: Display Channel Status details.
CHANNEL(AG.QMCCE001P) CHLTYPE(SVRCONN)
BUFSRCVD(6791292) BUFSSENT(6791287)
BYTSRCVD(733238641) BYTSSENT(769989486)
CHSTADA(2026-01-27) CHSTATI(01.54.29)
COMPHDR(NONE,NONE) COMPMSG(NONE,NONE)
COMPRATE(0,0) COMPTIME(0,0)
CONNAME(10.200.1.41) CURRENT
EXITTIME(0,0) HBINT(300)
JOBNAME(0000D49600000024) LOCLADDR(::ffff:10.200.1.22(1416))
LSTMSGDA(2026-01-27) LSTMSGTI(17.53.15)
MCASTAT(RUNNING) MCAUSER(usragrccep)
MONCHL(OFF) MSGS(6791277)
RAPPLTAG(icexsd) SECPROT(NONE)
SSLCERTI( ) SSLCIPH( )
SSLKEYDA( ) SSLKEYTI( )
SSLPEER( ) SSLRKEYS(0)
STATUS(RUNNING) STOPREQ(NO)
SUBSTATE(RECEIVE) CURSHCNV(9)
MAXSHCNV(10) RVERSION(09000000)
RPRODUCT(MQCC)
The client reports that restarting our AG channel, whose IP address is 10.200.1.41, causes them to lose connection. They haven't provided any further details about the errors, so I need to ensure the channel is always active.
Tnaks !!
------------------------------
Ursula Jimenez Zegarra
Original Message:
Sent: Tue January 27, 2026 05:31 PM
From: Morag Hughson
Subject: MQ SERVER CONNECTION CHANNEL INACTIVE
Hi Ursula,
It would really useful if you could issue the following command when the client application is running:-
DISPLAY CHSTATUS(AG.*) ALL
I request the ALL on the end because there are lots of additional useful attributes that are shown if you do this. I'm thinking that we would like to see things like RPRODUCT that I mentioned earlier, and HBINT which on CHSTATUS shows the negotiated in-use value of heart-beat which *MIGHT* differ from the definitional value seen on DISPLAY CHANNEL if the two ends of the channel have different settings.
A non-zero value of DISCINT on a SVRCONN has the effect of timing out the channel if the application is idle for long periods, but you are not using that, so that is not the issue here.
We still need to see the error messages written, especially at the client end. What MQ Reason code do they receive for example? And what additional error information is written to the client error log or as an exception (depending on the type of application we are talking about here).
Cheers,
Morag
------------------------------
Morag Hughson
MQ Technical Education Specialist
MQGem Software Limited
Website: https://www.mqgem.com
Original Message:
Sent: Tue January 27, 2026 08:19 AM
From: Ursula Jimenez Zegarra
Subject: MQ SERVER CONNECTION CHANNEL INACTIVE
Good Morning Francois !!! Thnks for answering me !!
The parameters in the channel is :
2 : dis chstatus(ag.*)
AMQ8417I: Display Channel Status details.
CHANNEL(AG.QMCCE001P) CHLTYPE(SVRCONN)
CONNAME(10.200.1.41) CURRENT
STATUS(RUNNING) SUBSTATE(RECEIVE)
dis chl(AG.QMCCE001P)
3 : dis chl(AG.QMCCE001P)
AMQ8414I: Display Channel details.
CHANNEL(AG.QMCCE001P) CHLTYPE(SVRCONN)
ALTDATE(2022-04-12) ALTTIME(19.31.20)
CERTLABL( ) COMPHDR(NONE)
COMPMSG(NONE) DESCR( )
DISCINT(0) HBINT(300)
KAINT(AUTO) MAXINST(999999999)
MAXINSTC(999999999) MAXMSGL(4194304)
MCAUSER(usragrccep) MONCHL(QMGR)
RCVDATA( ) RCVEXIT( )
SCYDATA( ) SCYEXIT( )
SENDDATA( ) SENDEXIT( )
SHARECNV(10) SSLCAUTH(REQUIRED)
SSLCIPH( ) SSLPEER( )
TRPTYPE(TCP)
And the hbint is 5 seconds , How can I validate at the network level that this parameter is correct? Thanks
------------------------------
Ursula Jimenez Zegarra
Original Message:
Sent: Tue January 27, 2026 07:38 AM
From: Francois Brandelik
Subject: MQ SERVER CONNECTION CHANNEL INACTIVE
Hi Ursula,
You should also look at the heart beat interval of the SVRCONN channel and make sure it is less than any idle disconnect on any firewall between the client and the MQ Server.
Also think about your TCP Keep Alive policies (Server, qm.ini etc...)
Hope it helps
------------------------------
Francois Brandelik
Original Message:
Sent: Mon January 26, 2026 05:44 PM
From: Morag Hughson
Subject: MQ SERVER CONNECTION CHANNEL INACTIVE
If they lost communication then there should be an error recorded. You should work with them to find that error. You should see errors written to both the client error log (on their machine) and the queue manager error log (AMQERR01.LOG in the qmgr errors folder) on the machine where the queue manager runs. The exact location of the errors on the client machine will depend on the programming language they have used to write the application. You don't mention what that is, and it is possible that you don't know what that is (unless you have previously used DISPLAY CHSTATUS when the application was running and looked at the RPRODUCT field). They will have received a reason code on whatever MQ API call they were using when the loss of connectivity was detected. Probably a 2009 (MQRC_CONNECTION_BROKEN) but it could have been some others as well.
The most likely thing you will see for "communication loss" issues is something that reports the TCP/IP error code. Once you find that, you will learn more about the issue.
Rest assured that loss of communication cannot happen without some part of IBM MQ noticing and recording the error.
Cheers,
Morag
------------------------------
Morag Hughson
MQ Technical Education Specialist
MQGem Software Limited
Website: https://www.mqgem.com
Original Message:
Sent: Mon January 26, 2026 05:34 PM
From: Ursula Jimenez Zegarra
Subject: MQ SERVER CONNECTION CHANNEL INACTIVE
Thank you so much for your time in responding, Morag Your so kind !!.!!!!
I explain this to the client, but they indicated that the channel went into an inactive state, and they lost communication, which seems strange to me. Since we don't have visibility on their end(CLIENT), how could we run tests on our end to determine if there are indeed problems on their side? Perhaps a traceroute or something similar.
I want to sure our site MQ its fine , and probe it the error is by the client side
Thankss !!!
A Server conn channel cannot remain open indefinitely, such as the sender or receiver (Distinct 0).
------------------------------
Ursula Jimenez Zegarra
Original Message:
Sent: Mon January 26, 2026 05:19 PM
From: Morag Hughson
Subject: MQ SERVER CONNECTION CHANNEL INACTIVE
Hi Ursula,
I am happy to tell you that a SVRCONN channel being INACTIVE at certain times is not a problem.
Unlike QMgr-Qmgr channels like SENDER-RECEIVER channel pairs, which you might want to have RUNNING all the time (although with TRIGGERING, an INACTIVE SENDER channel is still not an issue).
SVRCONN channels are ONLY running when the client application is connected. Like this:-
Client App: MQCONN(X)
SVRCONN Channel starts up and goes into RUNNING state
Client App: MQOPEN, MQPUT, MQGET etc
SVRCONN Channel remains RUNNING
Client App: MQDISC
SVRCONN Channel ends and goes INACTIVE.
To confirm that the channel is working correctly, have the client run their application, and if the channel is RUNNING, and the application gets no errors, then the channel is working correctly. If the SVRCONN is no longer running when the client application is not running, then the SVRCONN channel is working perfectly.
Cheers,
Morag
------------------------------
Morag Hughson
MQ Technical Education Specialist
MQGem Software Limited
Website: https://www.mqgem.com
Original Message:
Sent: Mon January 26, 2026 02:17 PM
From: Ursula Jimenez Zegarra
Subject: MQ SERVER CONNECTION CHANNEL INACTIVE
I'm writing to let you know that we're apparently having a problem with an MQ channel, specifically a server connection channel.
It appears to be inactive at certain times, affecting the client. We've ruled out MQ issues since no errors are being written, but we want to know how to perform tracebacks to confirm that the channel is working correctly and that the problem lies with the app's client, mqcliente.
------------------------------
Ursula Jimenez Zegarra
------------------------------