Common errors: IBM® WebSphere® MQ applications on IBM® z/OS®
Certain common errors might be displayed while you are using IBM® WebSphere® MQ applications on IBM® z/OS®.
For other troubleshooting tips for WebSphere® MQ on Rational® Integration Tester that might not be unique to z/OS, see Troubleshooting: Websphere MQ.
Problem | Solution |
---|---|
Where MQPG is the queue manager name, and AMQ.CA40EF5E3FD3A36B is a queue name. |
Grant IBMUSER permission to access the context for the queue. |
Where QL01 is the queue manager name, and AMQ.CA91632290DFEA14 is a generated dynamic queue name. |
This error is caused by using the user ID ADMINISTRATOR in the tools. Use a valid MVS™ user ID instead. |
No messages are being recorded
|
Check the QMGR job log or the z/OS syslog
for the message |
No messages are being recorded, and you see this error when you stop
recording:
|
If your MQ RESLEVEL access and PUTAUT channel parameter prevent queue access
authorization checking, either change those parameters to enable authorization checking, or specify
the AUTHCHK(NO) parameter on the PARM statement within your Rational® Integration Tester Agent
JCL. |
You receive the message 2035 Not Authorized when attempting to record a
transport, or when attempting to record an operation whose Queue or ‘Reply Queue fields contain a
wild card value. |
Ensure that you have READ access to COM.GREENHAT.ALLOW.GENERIC.QNAMES. |
When you attempt to start recording, the following error message is produced:
|
If the queue manager is not part of a queue sharing group, ensure that the COM.GREENHAT.INTERCEPT namelist was created with QSGDISP(QMGR). |
When you start the Rational® Integration Tester Agent for a queue manager that is part of a queue sharing
group, you receive the following message:
|
Create the namelists required by Rational® Integration Tester. For details, see Testing with WebSphere MQ on z/OS systems. |
When you attempt to record, messages for some queues are not recorded while messages for the other queues are recorded successfully. |
Verify that no sift-and-pass-through stub is running for the queue. When using sift-and-pass-through stubbing with fixed queues, a stub that fails due to network or
other errors can leave a rule in the RIT.DIVERT.RULES namelists. The remaining rule in the name
list can also cause this problem. To reset the RIT.DIVERT.RULES namelist, stop all stubs and run
the following command: For an example of a batch job that runs the command when using Rational® Integration Tester with a single queue manager, see the RITIVP3 job. For an example of a batch job that runs the command when using Rational® Integration Tester with a queue sharing group, see the RITIVP3G job. |
When running a stub involving messages containing multiple character sets or types of encoding within a single message, you might receive unexpected errors similar to the following:
|
With these messages, the Rational® Integration Tester recording studio might need to process the MQRFH headers manually, rather than depending on the MQ API to do it. To force the MQ API to allow Rational® Integration Tester to process the headers, specify the option MQGMO_PROPERTIES_FORCE_MQRFH2 as one of the default get/take message options on the Options tab within the Rational® Integration Tester MQ transport definition. |
When you record a transport, the text within the body of the recorded message is not comprehensible. |
Depending on the version of the MQ libraries that you defined in Library Manager, you might need to add MQGMO_CONVERT as a Get/Take Message option on the MQ transport Options tab. |