It is not normal for an MQPUT call to take very long. This is why it doesn't have a timeout. Do you know why your MQPUT calls are taking several seconds? it might be worth digging into that rather than trying to work around it by trying to have a timeout in the application. If you don't care whether the put works or not and want to have a true "Fire and Forget" so that you don't have to wait for the network line turn-around to send back the return code, you could look into MQPMO_ASYNC_RESPONSE.
If you lower the HBINT on the channel (at both ends) then this will mean the MQGET calls will wake up to send a heartbeat flow ore frequently.
What are "persistent connections"?
So this post finally answers the question about why your MQPUT is taking a long time. You have auto-reconnect enabled which is designed to ensure that the MQRC_CONNECTION_BROKEN return is not returned back to the caller of the MQPUT and instead it waits and remakes the connection and ensure the MQPUT is done successfully before returning. If you want to be notified immediately of the failure of the connection, you should turn off auto-reconnect and catch the return codes that it handles, yourself.
Auto-reconnect was designed for applications that are simple and can't cope with catching and handling non-zero return codes. Your application sounds like it is not only capable, but is expecting to do so.
You say that you have gotten around the extended period by disabling auto-reconnect. Could you say why you still need a timer around the MQPUT at this point? Is this the MQPUT that detects the failure of the connection? Are we now into the realms of how fast the client can detect the outage of the socket?
If you do use auto-reconnect, which I don't think you need to, you can use the event listener to tell you when the connection has gone.