Usually an EBCDIC-formatted IBM MQ message is automatically converted to readable text with no user intervention. However, there are two ways that can fail:
(1) The message does not have the correct character set given in its Coded Character Set ID (CCSID) field. Common CCSID values for EBCDIC are '37' and '500'. If it's left at '819' (ASCII) or '1208' (UTF-8) or any of hundreds of other possible CCSID values then the IBM MQ client library will decode the payload incorrectly.
Unfortunately, checking this in 7.5 is pretty difficult. You need to uncheck the 'Use payload as last response' checkbox and then add a script step after the MQ step:
return testExec.getStateObject("LASTRESPONSE").characterset;
Run the test in the ITR, and the response from the script step should show you the CCSID that is being sent. If it's not '37' or '500' then the IBM MQ client library is using the wrong character set to decode the message body.
(2) The message has the right CCSID value but the payload is not entirely plain text. Usually this causes the response from the MQ step to be a impenetrable blob of binary data. This is less likely to happen in 7.5, but if the CCSID you find with the above steps is the correct '37' or '500' then you may have a binary payload on your hands.
If all else fails then you can probably work around the issue by modifying the script step to actually do the EBCDIC decoding instead of just getting the CCSID value:
// This is mostly off the top of my head so it may not be 100% correct
message = testExec.getStateObject("LASTRESPONSE");
message.seek(0);
rawBytes = new byte[message.getDataLength()];
message.readFully(rawBytes);
return new String(rawBytes, "Cp037");